QUOTE(LaraLove @ Thu 22nd January 2009, 1:19pm)
QUOTE
Unlike Wikipedia, however, all user-generated changes to the Britannica will go through the encyclopedia's staff. Britannica is hoping for a turnaround of about 20 minutes between the submission and its appearance on the site--a pretty hopeful standard, should the site's new incarnation achieve anywhere near the same level of popularity as Wikipedia.
I don't think 20 minutes is very realistic in the long-term. Perhaps in the short, short term. If there is any success at all seen here, without a large staff, that's just unrealistic. The fact that there is a wait will most likely encourage larger edits, which will take longer to verify.
Now, let's see how a good ergonomically-sophisiticated engineer would go about this.
First, you do a sample for submitted articles which are awaiting approval, to find out what the characteristics of the set of times between submission and approval of articles is. This list and its stats will be dynamic, but you can do a sample of it statistically every week, or even every day, if you must.
That gives you an expectation curve-- a list of all submitted but yet-unapproved articles and dynamic times (a ticking meter for each) which gives the time since each article has last been submitted for approval, and the time NOW. A statistical look at the "caller on hold wait time" problem, if you want to look at it that way.
Then you break those down, by wait-time, into bins. Quintiles or deciles, or whatever number of reasonbly distinct colors a standard display can support. You do this so that each "delay and waiting bin" has roughly the same number of articles in it (or whatever fraction you choose, but it's constant), and thus the time-range each bin represents, will vary widely.
The first bin (for example) might be anything from 5 seconds to 5 minutes, but the second might be 5 minutes to 30 min or something. Whatever it is, the range of each bin is adjusted by fraction of articles out of the total it holds, so looking at it from less-to-more, is always a look at the line of first-come-first-serve for articles "on hold", no matter how much editorial help you have on any given day, and what the mean or mode times happen to be on that day. So the bin parameters are a relative thing, which correct for amount of help available automatically.
And then you color-code those articles by waiting bin queue, when they show up on a Watch List. Articles which aren't on "wait" or "hold" can be black. Everything else can be a color that varies by where it is in line. A nice cool purple for just approved recently but waiting on a new submission, going to blue for longer wait, to green for longer, to yellow, and finally to orange and red for waiting a hell of a long time (say, for longer than 90% of the other articles that STILL have not approved.
Then, when somebody doing approvals of flagged submissions pulls up their
Watch List of articles they're already acquainted with, they see what needs to be done the worst, right off. The colors tell them.
If you like, you can also do something like this for some subset of the whole "waiting evaluation" article pool, so editors can see some subset of articles (got to figure out ways to pair this down) that they've never seen, but again arrayed by need for attention like callers on hold, in a way that is immediately obvious. Some people may actually enjoy getting articles they'd never seen, but that have been waiting a REALLY ong time for parole from the flagged doldrums or "needs looking at" category. Articles shouldn't have to suffer just because they aren't on many people's watch lists. However, articles that are on more watch lists probably should get some special treatment for that, and this system does that.
Milt