Upgrading Collaborative Logs

Summary:

Together, we could upgrade the universe.

Upgrading Collaborative Logs

AJMansfield 14 Apr 2017 22:53

The SCP-2673 Containment Maintenance Log has been upgraded to allow it to be more easily managed and to allow individual entries to be voted on. The same code could, with fairly minor modification, be applied to other logs, including the ones listed here.

It will, however, take a significant amount of manpower to migrate the existing log entries over to the new format. While copying the entries themselves wasn't too big a hurdle, creating the attribution metadata for the new posts was very time-consuming even just for SCP-2673's log, and would be even more so on larger logs with more complicated edit histories.

• Should the other logs be upgraded?
• How important is it to have correct attribution metadata for log entries?
• How should entries be sorted on the large collaborative logs?

Last edited on 14 Apr 2017 23:24 by AJMansfield Show more

Re: Upgrading Collaborative Logs

AJMansfield 14 Apr 2017 23:09

My thoughts on the issues:

Should the other logs be upgraded?

Absolutely yes.

How important is it to have correct attribution metadata for log entries?

I'm uncertain. Especially because, if we migrate and then delete the old log page, all the existing attribution data will be permanently lost. There might be a way to automate migration, but attributing individual log entries is not a simple task.

How should entries be sorted on the large collaborative logs?

I am also unsure here. Some of the ways they could be sorted, and consequences of each:

• Sort by a static randomly-assigned ID numbers.
  • They will always be in the same order, so someone wanting to read all of them could do so over multiple sittings
  • But there's no way to control the order to keep related entries next to each other.
• Order randomly
  • The order is no longer static.
  • Newer entries will theoretically be able to get exposure occasionally, but that means that the lists will keep growing indefinatly.
  • Related entries will almost never be next to each other.
• Sort by best score first
  • Users will be able to easily find the best ones and don't need to wade through piles of mediocre ones.
  • Will lead to dogpiling and make it very difficult for newer entries to get exposure.
  • Can't control the order
• Sort by worst score first
  • Bad entries will be quickly downvoted and filtered out of the lists.
  • But really really good entries will only be at the end.
  • Can't control the order
• Sort by oldest first
  • Groups related entries together
  • Older 'classic' entries will get exposure
  • but newer entries won't get exposure
• Sort by newest first
  • Groups related entries together
  • New entries will get exposure
  • but older entries won't get exposure

Note that it would be possible to use URL parameters and allow users to change the sort order to whatever they want, but one of these is going to have to be the 'default' sorting method.

Last edited on 14 Apr 2017 23:10 by AJMansfield Show more

Re: Upgrading Collaborative Logs

RJB_R 15 Apr 2017 17:21

It looks good and is functional, but on larger log pages wouldn't the loading times be totally unbearable? If it's already this slow on a relatively small and untrafficked page I don't think it'd work on something as massive and sprawling as our other big test logs. I would be in favor of applying this to the smaller pages, but unless it can be made to work with less loading I don't think it's feasible for the big test logs.

---

Whether you like it or not, history is on our side. We will bury you!

Re: Upgrading Collaborative Logs

Dexanote 15 Apr 2017 17:58

I agree here, especially for 682 and 914s logs. Theyre the most popular and dont really NEED this anyway, since theyre tremendously popular and may or may not be taken care of and pruned in the near future. Smaller logs will benefit from the novelty and stylepoints.

A thing i forgot earlier was that some older logs (like 682, 914, Dimensional Hopper) have 'stage setting' entries early on from the authors that while theyre simple and straightforward they establish the rules of the log through inplication.

Re: Upgrading Collaborative Logs

RJB_R 15 Apr 2017 19:35

A thing i forgot earlier was that some older logs (like 682, 914, Dimensional Hopper) have 'stage setting' entries early on from the authors that while theyre simple and straightforward they establish the rules of the log through inplication.

Noting that the wikiwalk team also took this approach in making the telekill alloy collaborative test log.

---

Whether you like it or not, history is on our side. We will bury you!

Re: Upgrading Collaborative Logs

AJMansfield 15 Apr 2017 21:45

I'm not sure what test log you are referring to, the only test log I'm aware the WikiWalk team has added is the SCP-143 Testing Log.

Re: Upgrading Collaborative Logs

RJB_R 15 Apr 2017 21:50

I meant the bladewood Grove. I have no idea why my brain went to telekill :P

---

Whether you like it or not, history is on our side. We will bury you!

Re: Upgrading Collaborative Logs

AJMansfield 15 Apr 2017 22:03

To be honest I'm kind of disappointed actually, I wanted to read it. :(

Re: Upgrading Collaborative Logs

AJMansfield 15 Apr 2017 21:23

may or may not be taken care of and pruned in the near future

Part of the original intent, at least, was that this could be used to make pruning more 'automatic', as low-scoring entries would be automatically removed from the list.

A thing i forgot earlier was that some older logs (like 682, 914, Dimensional Hopper) have 'stage setting' entries early on from the authors that while theyre simple and straightforward they establish the rules of the log through inplication.

In that case an 'oldest first' sort would probably be best for those logs, if we did want to peruse this on those longs.

Re: Upgrading Collaborative Logs

Dexanote 17 Apr 2017 06:48

My issue with automatic pruning is that genuinely good or necessary parts of logs may be lost if enough people find them useless for one reason or another (whether because they rely on other stage-setters to build on implication, or are simple and basic stuff like 682 vs Contagious Crystal or 914 vs Pocket Watch that don't pop but are necessary ambiance-builders).

And… I would rather this not be initiated on hueg SCP logs (specifically the Big Three Collab Log pages of Series 1, 682/914/Vending Machine) until I'm 100% sold on its execution. I echo Bright's view here, it seems… kind of a lot for a little. I'm going to keep tabs on the 2673 demonstration for the next few days to see how it pans out.

If the first test run does go well I'd love to see this put onto Log of Extranormal Events or Unexplained Locations to see how it fares with a Larger But not Biggest sized collab page.

Re: Upgrading Collaborative Logs

ProcyonLotor 17 Apr 2017 07:04

Very much my thought as well. I'm simply not seeing the benefit added to justify the work.

Re: Upgrading Collaborative Logs

AJMansfield 15 Apr 2017 21:18

One way to mitigate the page loading issue if we do want to apply it to larger logs, is just use pagination. Wikidot already paginates ListPages modules by default at 20 items, but this could be dropped down to just 10 or even 5, since the entries are not just lists of links like in most ListPages.
Paginating logs would normally break the page anchor feature, but I worked out a partial workaround that still lets us link directly to specific entries, with a caveat that if the entry order changes it will break at least some of the links. To demonstrate this, I've added this feature to the SCP-2673 Containment Maintenance Log and changed its perPage limit to 5, bringing my load time down from 8 seconds to only 3.4 seconds.

Last edited on 15 Apr 2017 21:28 by AJMansfield Show more

Re: Upgrading Collaborative Logs

AJMansfield 15 Apr 2017 21:35

Just for reference, some of the comments I've received on the test page:

TL333s: (link)

I've never seen a page with multiple rating modules before. o.O Can we get that on Extranormal Events, I wonder, to help clear out the chaff?

-9Volt-: (link)

I imagine that would be a much more significant undertaking (there's a lot of entries you'll need to make into semi-pages), and if done the Anomalous Items and Unexplained Locations will need the same (which will also take a lot of effort). I'll agree that it could help with quality, so it may be worth it.

Re: Upgrading Collaborative Logs

AdminBright 17 Apr 2017 04:41

Sorry, I'm still not sold on this. It feels like a lot fo work, for not much pay off…a nd would require people combing back through and voting on all the entries… *shrug* I just don't see it helping more than harming.

---

Admin, SCP Wiki

Re: Upgrading Collaborative Logs

Doctor Cimmerian 17 Apr 2017 10:25

I've been giving this some thought: This is an interesting concept and it is, objectively, a better system. But like a few folks have said already, it's not head and shoulders above what we do now. It's a very very nice tool to have in the arsenal, and I'd like to see it applied perhaps on logs going forward (along with, perhaps, some of the shorter older ones).

Before I straight up go "nah this won't work for older logs" I'd have to see it in action on a giant list. Right now I don't think this would work out too well for older giant logs. Prove me wrong.

(Also attribution metadata is incredibly important, as I mentioned in chat)

Last edited on 17 Apr 2017 10:26 by Doctor Cimmerian Show more

Re: Upgrading Collaborative Logs

sirpudding 18 Apr 2017 20:54

One thing that is apparent now from SCP-2673's log is that preserving the old discussion thread is non-trivial. I ended up printing it to PDF and then saving it to files, but it's only 36 posts.