Purpose of This "Document"

I have decided to prepare this page after much discussion beneath Anna's update proposal. It is intended to be a complete system combined from proposals throughout these
discussions (and elsewhere), as opposed to Frankie Roberto's overall summary of discussion points.

It is almost entirely not my idea, but combined from the comments of other researchers - although I'm afraid I can't remember who said what and give credit where it's due, so I've decided to include only the ideas themselves. Please feel free to comment on this proposal, either on this page or on the forum where most of the ideas were developed, and I hope to either justifiably reject or accomodate any criticisms in due course. This is only a second draft, and I intend to update this page as I go along but once finished I intend it to cover every aspect of the new system.

As suggested by ResearcherPSG, I have added a "current problems/disputes" section (at the end), so that each can be easily referred to, and I have also attempted to show what the system will look like from the researcher's point of view.

A Two-Part System

The need for seperate routes

Many people have pointed out the difference between minor changes (such as adding a link, correcting an error, or updating one particular detail) and completely rewriting an out of date or badly written (such as some of the earliest Edited Entries) Entry. The emphasis for the system for dealing with the first type is on speed and the ability for anyone to point out the change, whereas the second needs a more comprehensive discussion, much like the Peer Review process the original version will have gone through.

The user's point of view

The first thing a researcher should see when trying to update a page is some kind of explanation. Therefore, under the current proposal, they will see a link labelled with something like "If you wish to discuss this entry, or suggest minor alterations or corrections, click here." and a button marked "Request ReWrite". The former will go straight to the "Route 1" update system, while latter will take them to a screen pointing out that minor changes are more effectively dealt with through the "Updaters" system. They will then be offered one link to use the "Route 1" system instead, and one to press ahead with making a complete ReWrite under "Route 2".

Route 1: Minor Changes

The user's point of view

If the user has spotted a minor fault, correction or update to the entry, they will be taken to some form of discussion forum, where they can explain what they think needs changing, and comment on the suggestions made by others.

Alternative forms of the conversation

This is currently one of the most contentious parts of this proposal, and several variations and alternatives have been suggested:

• Existing forum structure: Every Entry can have an unlimited number of discussion threads attached to it, and these
  allow discussion of any related points by any researcher. The changes can then be implemented by an Updater only once a conclusion has been reached. There is also the advantage of existing conversations being automatically taken into account when the new scheme starts, rather than an intermediate system being required. However, it may be that such suggestions become "lost" amongst the sheer volume of postings about the topic of the Entry, and so will not be seen by those in a position to comment.
• A seperate "update conversation": A dedicated forum could exist on (or attached to) each Edited Entry, where updates could be specifically discussed. This has been compared to the (successful) PeerReview forums, but remember that we are only talking about relatively minor changes here, so the collaborative element is not quite the same. There is also nothing to stop "topic drift" occurring in this thread, just like in all the others, and once several changes had been suggested, this could lead to a long and near unfollowable thread. This also restricts the update conversation to one topic at a time, rather than the useful ability to have multiple parallel threads in the overall forum, each with a specified topic.
• A special "alert updater" check-box on the posting itself: When adding a posting to a forum, a user could be given tick boxes to alert an appropriate volunteer that this isn't just idle chit-chat, but requires attention. However, if the button was not spotted, the posting would presumably be ignored by the "officials", as would all postings predating the Update scheme - whether relevant or not. Additionally, it would only make it stand out as far as the Updaters were concerned, not other Researchers in general, and since the Updaters' only job is to read through forums anyway, this seems to be the wrong way around.

The Update Queue

Every Edited guide entry would be placed somewhere in a queue, based principally on how long since it was last updated. A group of volunteer "Updaters" would look at this queue, and pick an entry. They would proceed to this entry, reading through all appropriate forums/postings (as defined above) since the last update date*, looking for suggested changes. Once they had read through all the postings, they would make any changes, and the update date would be set to today's date. In essence, they would perform a similar task to a SubEditor - given an entry and some discussion, they would clean it up and pass it up to the Editors.

The alternative: Alerting the Updaters

In order that changes are dealt with more quickly, researchers posting changes could automatically alert an Updater. This however poses the problem of when it is useful for the Updater to know about a suggestion. In order to allow any discussion, they would have to ignore these for a certain length of time to allow other researchers to make comments*. This could be a long while, given the non-instant nature of forums, and poses the problem of how to keep track of who is aware but waiting on which thread. There is also a workload consideration, since notification puts pressure on the Updaters to at the very least subscribe to the thread, whereas a simple queue can be worked through at whatever rate fits their numbers and respective lives.

The Updaters' point of view

After reading the appropriate forums/postings associated with an Entry, an Updater would have a set of options based on what action was needed at this time:

• Edit Page: This would allow them to make a few small changes, and click "Return to Editors" as would a SubEditor*. The Editors would then be given a version with the change highlighted, and as long as they judged it a minor change (i.e. the overall content of the entry had not changed since original SubEditing), the page would be updated.
• Suggest ReWrite: This option would be used when the changes needed / suggested were too major to apply while keeping the overall Entry intact, and would be a request for someone more knowledgeable to write an updated version (see "Route 2").
• No Change Necessary: If the forums included no suggested changes, the Entry could simply be marked as having been updated, and sent to the back of the Update Queue, without any action being taken.

"Volatility"

Since not all pages will need updating with the same frequency, some form of prioritisation may be useful. There is also the possibility that an Updater will come across a conversation in full flow, and not want to implement the change until it is complete. It would be unproductive for such pages to simply stay at the top of the queue, and other changes may need to be made meanwhile.

Consequently, the Updater should be given the option of returning the Entry either to the very back of the queue, or to some point half-way through, so that it will be reconsidered after a short while. The exact postitioning of these midway points, and the reasons for using them, will have to be decided depending how quickly the Update Queue is worked through once the Updater scheme is running, as this will depend how many people work on it and how fast. There seems little point storing the perceived volatility of an Entry, as it may vary over time, as may the speed of processing of the rest of the queue, so it would seem to add more complexity than functionality.

There is also the option of having certain events automatically raise the position of an Entry in the queue. Depending on the forum system used, the existence and volume of postings suggesting changes could automatically be measured, and used to prioritise the queue. This adds more complexity to actually implementing the system, but may be useful depending how long the Queue takes to be processed.

Route 2: ReWrites

The user's point of view

If a Guide Entry becomes hopelessly out of date, or is just generally hopeless (such as some of the earliest Edited Entries), a researcher should be able to click a button requesting to completely ReWrite it. Although the original author should still be credited (and possibly notified), it may be necessary to replace almost all the content of an entry. This could be achieved through a "Request ReWrite" button, which would (after confirmation, as outlined above) take them to a copy of the Entry's source which they can edit as a normal entry. While they worked on this, the button would be replaced with a message saying that an updated version was in progress, with an appropriate link.

Within a certain time-limit, the new version would be submitted to a PeerReview forum (possibly a seperate category for Updates), where it would be discussed, Scouted and SubEdited much like any new Entry. The time limit would apply from clicking the "Request ReWrite" button to submitting it to a Review Forum, and would ensure Entries did not become "locked out" if a user abandoned a ReWrite. When finally Edited, however, it would replace the original version, gaining its A-number (and therefore all existing cross-references). The previous version would either be discarded or archived in some way that showed it to have been replaced (this has been discussed, but with no firm conclusion).

The ReWrite Market

If an Updater, or any other researcher, comes across an Entry which is in urgent need of a complete ReWrite, but feels unsuited to do it themselves, they should be able to alert the community to the need. This could take a similar form to the FleaMarket - a page where Edited Entries could be placed to gain the attention of someone looking for something to write. Picking an Entry from here would simply consist of going to it and clicking its "Request ReWrite" button, whereupon it would be removed from the "Market".

Systems Required

1: Route 1: Initial inauguration of Updater Volunteer scheme

• The volunteers themselves (Badge, eGroup*, etc.)
• Last Updated Attribute (All Edited Guide Entries need an additional date, changed whenever an Updater accesses them. For new and existing entries this will be initialised to the creation date.) A related point is how easy it is to spot "all postings since a specified date", but this depends on the forum structure used.
• The Update Queue (At first, just a simple list of Edited Guide Entries, arranged by Last Update Date)
• Access Rights and Change Submission for Updaters (On investigating a page, an Updater should have extra options to recommend a simple change to the Editors. The Editors will see only this change, or see it highlighted, based on a comparison between the old and new source, and can reject it if it changes too much).

2: Route 2: Ability to request a copy

• "Request ReWrite" Button (Confirms understanding of system, clones page, and is replaced by a link to the newer version)
• Consider changing "Discuss" button (If it is not obvious to users that this is how minor changes are suggested, perhaps the text of the link to make a new conversation could explicitly give this as a purpose)
• Time Limit (So that Edited Guide Entries don't end up locked out by lazy researchers, unlink the clone unless it is submitted for review within a set amount of time)

3: Enhancements to Route 1

• Volatility Judgements (Allow the Updater to choose where in the Update Queue the Entry is placed. Also, consider automatically raising an Entry through the Queue based on forum activity.)

4: Enhancements to Route 2

• ReWrite Market (Allow users to place an Entry in a special list requesting others to ReWrite it)
• "Needs ReWriting" Option for Updaters (Allow the Updater to send the Entry to the ReWrite market as an Update Option, allowing it to be sent to the back of the queue until the new version is ready.)

Current Problems and Discussion Points

A: Use of Forums

As discussed above, there is much discussion over whether to use the existing forums underneath Entries, a seperate Conversation, or a highlighting/alerting procedure. The main problem is finding the postings, and how obvious the system is to new users. Be aware, however, that this is not equivalent to Peer Review, as this is only the procedure for single minor changes.

B: Inclusiveness

Some people have argued that anybody should be able to make a change, just like anybody can write the original Entry. However, they can't do this without going through Peer Review, and this is how Route 2 would still work. However, Route 1 is essentially intended as a short-cut to this, where only small changes need implementing and can be quickly passed through to the Editors. However, to reduce the workload on the Editors themselves, this proposal gives only Updaters the right to make such changes. This is not without its critics, mostly because it means the researcher will have to wait for their change to take effect. On the other hand, it is faster than the current (indefinite) delay.

C: Queue versus Notification

Not everyone agrees that working through a queue of all entries is the most efficient method. Its advantages are that it takes into account every Entry, and all existing postings; and that it can be worked through at any pace without the system becoming any more or less clogged up. Its disadvantages are that it is potentially slow, with time being taken up looking at Entries that are fine anyway. If one of the alternative forum systems was implemented, the queue could include only those Entries which needed attention. However, it is yet to be seen how long the queue will take to work through, as we don't know how many Updaters there will be, or how much work they will do. Also bear in mind that some Entries have very few postings, and will therefore take very little time to process.

D: Prioritisation of the Queue

This proposal currently contains a system of sending to different points in the queue, but others have suggested a "Volatility" rating for each page, or an automatic prioritisation based on number of postings. This depends largely on the outcomes of Discussions A & C.

E: Time Limit for ReWrite Submission

Although this has not so far been discussed, if a time limit is to be used for locking out the "Request ReWrite" button, its length needs to be determined such that there is time to write the Entry before submitting it to Review, but not so much that nobody will be able to re-start an abandoned effort.

F: New Review Forum?

Should the ReWrites in Route 2 be placed on the existing Peer Review page, or should a seperate page be created? Also, should the Scouting and SubEditing be identical, or should there be any differences?

E: Discard or Archive

This proposal currently does not address the issue of what happens to the previous version, especially after a Route 2 ReWrite. A good summary is on Frankie's page, but the main choice is whether to delete it altogether, or have some specific system of keeping an archived copy. It has been pointed out that this would probably need to be excluded from search results, to avoid them getting too long.