Hello all -
sorry it took me a while to respond, but these are very complex issues
and I don't want to reply with half-assed reasoning. ;-)
First, as you may know, I've been a proponent of having per-page
settings for the default view from day 1 (in fact, more accurately,
from day minus 120 or so ;-). Florence and Jimmy also support this, so
we'll get it done one way or another. But I also want to be clear that
I fully support the autonomy of the German Wikipedia in deciding how
to configure this feature. Unless and until we hear of a major revolt,
the Board is not going to intervene. ;-)
So, take this reasoning not as an attempt to argue with de.wp people
about how they should use this extension. I'm completely fine with the
original proposal being followed to the letter there. But be assured
that I will make the following argument as strongly as I can when it
comes to deployment on the English Wikipedia.
I believe that the vast majority of Wikipedia articles benefit from
massively open, collaborative editing. Instantly seeing your changes
"go live" is a pretty core element to this massive collaboration.
There is no waiting period. Importantly, we do not have _any_ clue as
of this point in time how quickly we will typically sight edits.
Maybe it will be very manageable, since it only applies to untrusted
users & only once a first version in this particular article's history
has been sighted. My fear is that an unregistered user may, in some
instances, have to wait days or weeks until an edit they have made
actually becomes "live" for the whole world to see. And my concern is
that this will reduce the number of experimental, "just for fun" edits
that gets many people hooked on Wikipedia in the first place.
Will it actually make Wikipedia better if we do this on _all_
articles? Arguably, the vast majority of (English) Wikipedia articles
still need a lot of work. They are full of maintenance templates,
spelling errors, missing citations (and associated templates),
inconsistencies and contradictions with other articles, stylistic
issues, and so on and so forth. For all intents and purposes, many
_are_ in the draft stage.
The _occasional_ bit of vandalism is a part of this drafting process,
as far as I'm concerned. You deal with it (you revert it), and you
improve the draft. Now some of our articles reach much higher quality,
and they truly deserve to be cherished and protected.
It's at this point that processes like "Good Article Candidates" and
"Featured Article Candidates" kick in. They currently don't scale very
well, and perhaps FlaggedRevs can also help with this a little bit.
But in essence, they are the articles that have actually left the
"draft" stage.
It's at this point that I think we should ask the question: Does it
benefit the reader, the main authors of the article, and the article
itself to have massively open collaboration? Because, clearly, in
many cases it does not: Articles actually degrade in quality, editors
are fearful of having "their" article listed on the Main Page because
of the amount of vandalism it will get, and so forth.
It's here that I would change the per-page default view to the last
"sighted" version of the page, still being _fairly_ open in
collaborating on it, but slightly less so than on other pages.
There are other cases where we can safely say that articles do _not_
benefit from massively open collaboration. These are the ones that are
currently, typically, in semi-protection due to edit warring and
vandalism. Here, too, I think it makes sense to change the default
view.
Finally, there are specific groups of editors -- IP ranges -- that are
causing a lot of trouble: schools, open proxies, anonymization
networks, and so on. I would have no problem requiring _all_ their
edits to be "sighted" before they go live. (I understand that this is
a different technical proposition altogether, and don't expect it very
soon.)
Note that, as Jimmy said, this would (in the overall tendency) make
Wikipedia _more_ open: You could edit pages we currently protect,
allow edits by user groups we currently block, and so on. However, I
believe we could _gradually_ broaden the number of pages we treat in
this way, as their overall quality increases and we become more
comfortable with the feature itself. It's always a tradeoff between
the benefits of open collaboration and its drawbacks.
All that said, the process of sighting should be global, and the
information of what versions are sighted should always made be
available to the user, regardless of what the default view is. And for
offline applications like DVDs, you'd be picking the most recent
sighted version.
Regarding Kurt's argument of gaining trust, I think making _whichever
we do_ as transparent as possible will already go a long way towards
that. So, if the reader knows that they're looking at a highly dynamic
"draft" but can switch to the most recent sighted version, they're a
lot less likely to a) print the unstable version and put it in a
brochure, b) take everything in it to be the sacred truth.
This proposition is not as complex as it first sounds if you consider
that it would largely replace the current "semi-protection" which,
with its scary "view source" links and meta-templates, is quite a lot
worse from a usability POV. I call this new per-page mode "quality
protection", and it should be hooked into the standard page protection
UI. I do not have a problem with sysops performing this operation,
(since it should be a fairly routine process that does not require an
editorial judgment, like protection is now).
A lot of the complexity also goes away if you stop treating registered
and unregistered users differently, which is a lot more justifiable
when only a small number of pages are treated in this way. As Philipp
pointed out, if we make it reasonably intuitive to edit when the
latest version _is_ the most recently sighted one, this should not be
a problem, and will only drive editors to sight unreviewed edits more
quickly.
Aaron - if you're not going to work on this, I'll spec it out and
we'll get it done in some other way. As Jimmy said, I think it's
pretty critical to have this functionality before any deployment on
en.wp.
I'll give some more feedback on UI issues once we go into a first
public (widely announced) beta. We should have another discussion in
the near future about possible integration with Luca de Alfaro's work
-- I think algorithmic filtering of revisions and human annotations
could be nicely complementary.
Post by Aaron SchulzIt's been considered. I've never really got the reasons for it though. Who
determines whether the stable version is the default or not? I don't like it
being sysops, and if is 'sighters'/whatever, then what would that really
accomplish? If the issue is that is would get outdated, then people
shouldn't review things no one will follow up on enough.
It also requires another table just to store whether to make the stable
version the default. Plus, it makes the interface more complicated and what
version is the default seems more random and confusing to readers.
;)
-Aaron Schulz
Subject: stable versions... a few thoughts
Date: Wed, 29 Aug 2007 21:50:49 -0400
I think it is absolutely (absolutely!) imperative that stable versions has
to be enabled and disabled per-page, like protection or semi-protection.
If it is not, then there is just absolutely no way it will ever go on
English Wikipedia - and not likely anywhere else either.
Is that contemplated? Can we make sure it does that?
_________________________________________________________________
Now you can see troubleā¦before he arrives
http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_protection_0507
_______________________________________________
Wikiquality-l mailing list
http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
--
Toward Peace, Love & Progress:
Erik
DISCLAIMER: This message does not represent an official position of
the Wikimedia Foundation or its Board of Trustees.