This entry aims to summarise the arguments, discussions and proposals put forward in response to the proposal for an update system. Please feel free to point out any inaccuracies, omissions or missing credits. If I've credited you and you don't want to be associated with this entry, you can, of course, remove yourself from the researcher list (the joys of DNA 1.01!)

The Need for an Updating System

There was unanimous support for the need for an update system, and nobody suggested that it was a bad idea.

Changing A-Numbers?

A lot of people commented that the new version of the entry should retain the old A-number, rather than using a re-direction system. The reasons for this are; that it's been done this way in the past, that it's neater as links and references remain accurate, rather than re-directing to a new url.

Once this had been agree upon however, the problem remains about what to do with the old version. Some suggestions:

• Delete it, as people will only want to see the new up-to-date version (perhaps storing a back-up off-site just in case)
• Store it as a new conversation under the entry (though this might mean removing pictures)
• Give it a new A-number.
• Give it a new A-number only when major changes have taken place (though where do you draw the line?).
• Store it in an archive section of the guide that doesn't show up in searchers (eg 'dna/h2g2/archive')

A potential problem that emerged would be what happens if an entry becomes so big it needs to be split up. Suggested solutions were either keeping the old A-number as 'Part 1' of the updated version or as an index-style page linking to the different sections (similar to University Projects)

Crediting Systems

It is noted in the proposal that updating process would involve lots more people in individual entries, which might create problems with the crediting system, and so a new system was proposed. Some responses to this:

Rather than the complicated system proposed, the 'Edited by' credit could be expanded to allow more than one person to be named, and so all the different sub-editors could be put in this category, and all the different contributors added to the 'researched by' category as normal. It was noted that this idea has been in the Feature list for a while.

These credit lists might get very long. We could either allow this to happen (even though it might look scrappy, it's unlikely the list will be longer than the entry, and some entries such as this one have pretty long credit lists already), turn the list into a pop-up box if it gets beyond a certain number (say 10), or implement the short-name/long-name idea in the Feature suggestions, so that long adverts or titles in people's names don't clutter up the list.

Another possible idea is to implement the crediting-levels suggested in Feature suggestions, giving different credits for those who made a big and small contribution.

Entry Info

It was suggested that the most useful dates to appear in the entry data box would be the date the original was created (became Edited) and the 'last updated' date.

Levels of Updating

It was noted that whatever system was adopted, it ought to be able to deal with different kinds of updates:

• Those involving minor changes, such as fixing a typo, adding a sentance or two, or a link to a newly-edited entry. - Currently a lot of this is done using informal mechanisms, though perhaps not such a bad thing?.
• Those involving major changes, where a whole load of content is changed or added.
• Those involving the whole re-writing of old, inadequate entries (such as those from the Old Writing Team). - Perhaps these could just use the existing Peer Review system though.

Updating Process

The majority of the discussion was about how exactly the update procedure would work, with many people having lots of completely different ideas, some very different to the original suggestion. Some distinctly different ideas emerged.

Involving the Researchers More

One key concern that emerged was that the proposed system made it the work of the volunteers to do all the actual physical work of editing the new entry, all pressing the button does is to 'nominate' the entry. An alternative idea suggested was to involve the person pushing the button in the whole process, after all, it's likely that they if they want the entry to be updated, they can see some changes that they'd like to make themselves. This might help to open up the guide to newer people too, if someone comes along and reads an entry about something they know a lot about, they can suggest things to be added.

Most of the volunteers, Sub-Eds, Scouts, etc. are not required to have a deep knowledge of the entries - they are only concerned in editing the style, grammar and guideml of the entry, rather than the quality of the content itself. It would be better for people to choose what they update, based on what they know about.

Following these arguments, an idea was suggested that clicking on the update button could bring up a copy of the guideml of the page, allowing the researcher to make the changes themselves. Once the researcher had finished making their suggested changes, they could submit the updated copy to a review forum (either Peer Review or a dedicated new one) where other researchers could comment on the updates and suggest any changes/additions. Once everyone is happy with the updated version it could be sent off to be checked, either straight to the italics, or via a sub-editor (or new volunteer group).

One question with this process is how entries would get moved out of the review forum (once the updates have been settled). Would it be picked by a Scout, or sent off by the original updater? If Peer Review was used instead of a new forum, how would people know it was an update and not a new entry?

A suggested amendment to this procedure was a way to skip-out the review forum process if it was a minor update (see 'Levels of Updates'). This might speed things up, but the update could miss out on valuble reviewing and there's the problem of how you'd judge whether an update is minor or big enough to warrant spending time in a review forum.

Oh and the button would have to disappear (or pop-up with a relevant notice) whilst someone is working on an update or it is in a review forum, to prevent two people working on the entry at the same time.

Advantages of this system:

• It doesn't place too much of a burden on the volunteers, people who suggest the update do most of the work.
• It gives ordinary researchers the chance to play a part in writing for and improving the edited guide.
• Entries can be worked on as soon as potential updates are seen, rather than having wait until being picked.

Disadvantages:

• Entries are only updated as people come across them, rather than being worked through a systematic way.

(This system is based on an idea from Woodpigeon)

Going through the backlog

An alternative to this idea is the more systematic approach of a group of volunteers going through the backlog of entries, checking to see if any useful comments have been posted in the forums. To make this easier, entries could be queued according to when they were last created/updated, and possible a 'volatility' score, which rates how likely the entry is to need updating.

Assigning an updater to each entry

Another alternative is to assign an updater to each entry. It would then be there job to check if the entry needed updating. These updaters could either come from a new volunteer group (though it was calculated that you'd either need a lot of volunteers or each volunteer would have a lot of entries), or simply use the subs (though some might have left the site). The updaters would either update the entry with the new information, or check a box to say that the entry doesn't need it, sending it to the back of the queue.

Updating Tools

The original proposal pointed out that it'd be a waste of time to make the italics (and sub-editors, if they're used) have to read through the whole entry again just to check it. They'd have to be some mechanism to be able to highlight the changes. This would be useful for the community too, so that people in the review forum could see the suggested changes straight away and be able to comment on them. A good model for this is the 'compare documents'/'track changes' feature in Microsoft Word. The tool could compare any two documents, and then generate a page with new text marked as <INS> and deleted text marked as <DEL>¹. An option could specify whether to simply siplay the inserted text and hide the deleted text, or show the changes, using strikethrough and a underlining (or a red font) as above.

Other Notes and Ideas

• One suggestion was that perhaps the original author ought to be able to fast-track the updating of their own entry - they know the subject best after all.