On Sat, May 22, 2010 at 2:13 PM, Rob Lanphier <robla(a)wikimedia.org> wrote:
I'm preparing a patch against FlaggedRevs which includes changes that Howie
and I worked on in preparation for the launch of its deployment onto
. We started first by creating a style guide describing
how the names should be presented in the UI:
I'm concerned that the simplified graphical explanation of the process
fosters the kind of misunderstanding that we saw in the first slashdot
threads about flagged revision... particularly the mistaken belief
that the process is synchronous.
People outside of the active editing community have frequently raised
the same concerns on their exposure to the idea of flagged revisions.
Common ones I've seen "Won't people simply reject changes so they can
make their own edits?" "Who is going to bother to merge all the
unreviewed changes on a busy article, they're going to lose a lot of
None of these concerns really apply to the actual implementation
because it's the default display of the articles which is controlled,
not the ability to edit. There is still a single chain of history and
the decision to display an article happens totally asynchronously with
The illustration still fosters the notion of some overseeing
gatekeeper on an article expressing editorial control— which is not
the expected behaviour of the system, nor a desired behaviour, nor
something we would even have the resources to do if it were desirable.
In particular there is no per-revision analysis mandated by our
system: Many edits will happen, then someone with the right
permissions will look at a delta from then-to-now and decide that
nothing is terrible in the current version and make it the displayed
version. It's possible that there were terrible intermediate
versions, but it's not relevant.
I have created a poster suitable for distribution to journalists
(Though the lack of clarity in the ultimate naming has made it very
difficult to finalize it. If anyone wants it I can share SVG/PDF
versions of it).