[WikiEN-l] Flagged protection and patrolled revisions

Gregory Maxwell gmaxwell at gmail.com
Mon May 3 20:51:05 UTC 2010


On Mon, May 3, 2010 at 4:18 PM, phoebe ayers <phoebe.wiki at gmail.com> wrote:
[snip]

> 1. problem: no one understands what's going on.
> 1a. time should be spent, by someone who understands it -- and then by
> someone who doesn't to copyedit* -- on writing a very, very, very
> clear explanation of the flaggedrevs setup that is planned for
> implementation. Then this page can be linked to in whatever noticebox
> explanation that may or may not appear on editing. It can also be
> given to news reporters, because you know the "wikipedia has
> implemented review" stories are going to start flying once we set this
> thing up on en: (they already started flying when it was just a
> proposal).

Absolutely.  We need to pre-fab the PR on this to the greatest extent
possible.  Including an announcement of what we're going to do and
when,  then an announcement of what we've done.

But I don't think that any of that interacts much with the fine
details of how the implementation works.

I think that for usability we need to assume that the user has
probably missed all our fantastic announcements and explanations.

> 2. problem: psychology of the anonymous editor: what's the best
> outcome for a in-good-faith editor?
> 2a. we already disallow anons from editing semiprotected articles. So
> in lieu of that, having a box that pops up that says "this article is
> under protection, and therefore your edit is subject to review"
> doesn't seem so bad. Note this isn't necessarily a great solution for
> the entire site, but just for those articles that were formerly
> uneditable at all by anons.

This is absolutely true.  But I think it's completely impossible to
explain to a listener who isn't going to invest at least 5 minutes in
hearing our explanation.  So this is an important point on the PR
front, but I don't think we learn anything useful for software
usability from it.


> 2b. For editing in general (assuming it ever gets that far), I can
> think of a few test cases. My sense of the matter is that for
> experienced editors making a change is not such a big deal; each
> individual edit neither costs us much or is that important to our
> experience of the site. But if you are a new editor -- let's say a
> newly registered account or anon -- each change is worth a lot and is
> meaningful. I've certainly talked to a lot of folks interested in
> wikipedia who have told me, proudly, that they have made five edits.
> For those folks, their five edits are individually each important --
> important in their understanding of how wikipedia works and for their
> sense of being a contributor.
>
> That said, I think we need to try and imagine people's behavior around
> their edits.

This is basically the heart of my concern:  That one edit is
important, that it isn't lost is important.  That the site making it
disappear will be very upsetting for a least some people some of the
time.  ... and that no amount of explanatory boiler plate can
eliminate that problem because some people will miss it due to banner
blindness or simply not understand it.

> Would they go and look at the article again later (post
> session-cookie) to see if their change stuck? I think they probably
> would.

Absolutely.  But I would expect and hope that the median review time
is minutes, for typical and uncontroversial changes. If it's not— then
we need to improve the review process, because we're managing median
vandalism revert times less than that.

> I also think the experience of seeing an edit "go live" is
> pretty magical.

I think what we ought to try to do is to preserve the magic for
protected pages as much as we can.
Even with a full understanding of the implications— that your change
is on the draft page rather than the primary one, it's still pretty
magical.

This is important for new contributor relations because even if
protection is only ever used on the "small number" pages which are
currently semi/protected they all tend to be fairly high traffic
pages.  It's pretty likely that that flagged page behaviour will
completely define the new contributors first experience with
Wikipedia.  As you pointed out— delayed is better than denied,  but...


> So how we deal with this is dependent on 1, how flaggedrevs works --
> but I would think that some sort of clarifying statement -- who the
> edit is visible to, and where to go to see the version with the edit
> -- might be nice rather than the impression, on later viewing, that
> they've been reverted because their edit isn't showing up.

Full agreement, I think.  I just am concerned that we retain the kind of
positive outlook that you've presented here rather than the negative outlook
which focuses on how the contributor is being restricted.

[snip]
> 3. problem: we don't really know how this is going to pan out
> 3a. I see a lot of conflicting rhetoric about why we want flaggedrevs
> and what its role is. Indeed, if the goal is to promote wikipedia as
> more accurate (tm), then I see no special problem about notifying
> people that their edits are reviewed -- as Anthony says some might
> welcome it. If we want it to be an invisible process, part of the
> mysterious inner workings of the site along with template markup and
> RFCs, then Greg's idea makes more sense.


I don't think the goal of "More accurate™" is in conflict with
"Maximally inclusive in whom is allowed to edit".  Through the power
of the default-view and the power of transparency we can have _both_,
and I think the community has demanded a system which provides as
much.

The challenge here is that the initial impression for "review" and
"More accurate" is a secretive, restrictive, controlled, and slowly
moving system... largely because this what traditional mediums
provide. While "inclusive" is viewed as a crazy anything-goes anarchy
(which was never really applicable to Wikipedia, even before
protection).   I think the message we need to express is that we're
trying to combine the qualities of both extremes into a moderate
composite which is even closer to the radical openness of the early
Wikipedia while simultaneously being more accurate than the current
system.

I don't know how to craft a PR message around this because to an
outsider it sounds impossible for exactly the same reason that the
whole idea of Wikipedia sounds impossible.   People are very quick to
jump to the 'restrictive' understanding because it makes Wikipedia
finally make sense:  "See! radical openness really doesn't work!"



More information about the WikiEN-l mailing list