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.

On 8/30/07, Aaron Schulz jschulz_4587@msn.com wrote:

It'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.

Also, please use wikiquality-l@lists.wikimedia.org for stable versions stuff ;)

-Aaron Schulz

...

From: Jimmy Wales jwales@wikia.com To: jschulz_4587@msn.com 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 Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l