These are great questions, and we're actually having a big meeting about the project this afternoon, so I'll be sure to raise them to make sure we all have the same notion. That said, a few of quick responses from my perspective:
On 05/03/2010 08:15 AM, Carcharoth wrote:
Since it does seem very close to going live, could I ask if plans have been made for how to handle announcing the arrival of this feature and any post-implementation problems? Hopefully there won't be any or many, but are there plans ranging from "rollback completely if things go awfully wrong" to "make adjustments as needed and be responsive to concerns raised"?
There's the technical part of this and the community part of this. My understanding is that the technical side of the rollout is well understood, and that our substantial time in the labs environment means we are not expecting major problems. I also am given to believe that if there are major problems, rolling back will not be a big deal.
That will get us to having the feature enabled, but not in use. That next leg is mainly up to the community. Once the software is enabled, any admin will be able to turn on flagged protection for any page, just as they are now able to turn on full protection. I expect there will be a period of experimentation and vigorous discussion to discover exactly when that is a good idea.
Once it's in use on particular pages, there's the question of who does the reviewing, how much is needed, and how we make sure it gets done in a timely fashion. Most of that is up to the community as well, and part of the purpose of this experiment is to figure that out as well. From a technical perspective, there are a couple different approaches to deciding who has reviewer powers; in the next week or so I want to start a community discussion on the right model, but we need a little more internal discussion to be able to clearly present those options.
As far as the "making adjustments as needed", the plan is that we will absolutely learn things after release, and some of those things will probably require code changes. There is also a list of nice-to-haves that we can do if nothing else more pressing comes up. So work will continue as before, with frequent releases either to production or to the labs environment as appropriate. Once that work tapers off, I'm sure there will be a discussion of where best to allocate resources, but that hasn't even been mentioned yet; the Foundation is definitely committed to supporting this experiment.
And how much input exactly will ordinary editors have post-implementation? Is the interface flexible and can be changed by editors or admins, and which bits can only be tweaked by developers (either using common sense or following a community poll or Bugzilla request or request somewhere else)? I ask this partly as someone who (with others) may have to deal with any massive disputes or edit wars that break out over this if some aspects of flagged revisions or its interface are editable and changeable on-wiki (presumably in the Mediawiki namespace, editable by admins only).
This is an area where I'm personally a bit ignorant, so I'll be sure to ask. I know that some parts of the interface definitely require a developer to change code and release it. I know that some, possibly all purely textual changes can in theory be done hot, but I don't know who has the mojo to do that on the English Wikipedia. If somebody here knows that, please speak up.
Presumably, an update will be made to the on-wiki pages about this before it goes live? And there will some site notice giving some warning? having things change mid-edit could be a bit disconcerting!
My belief, which I will double-check, is that releasing the software will have little or no impact on the editing experience; it's only when an admin activates it on a particular page via the protection interface that the editing experience will change.
William