Last month, someone (from the US Navy, actually) wrote me to check on the status of my stable versions extension. I told him it basically should work, but has never been tested in a live environment. He got it to work (on a 1.6 MediaWiki) and tells me "everything is working fine", with some minor hacks he made, and which I checked into SVN for him. There is an issue with caching, though, which will prove to be no real obstacle but just a little work to fix it.
Sadly, I didn't have time to come to Wikimania this year, but I listened to Jimbo's opening speech today. I was very pleased to hear that finally, we're going to get stable versions, and as a German, I concur that de.wikipedia is a perfect testing environment for this (we've banned all non-free images, and stubs; stable versions are the logical next step). I also agree with Jimbo to just start with the simplest possible solution, see how it works, and modify it from there. Releasing software very early has been my motto from the start, much to the pain of our CTO ;-)
Anyway, I'd like to know if there'd be a point in me fixing the caching issue. Brion, will you roll your own implementation, or use mine? If it's the latter, should I apply final polish to it so you can get single login up and running first?
Apart from that, some general thoughts:
While the "simplest possible solution" would, of course, be another field slapped to the page table, it seems to me that any expansion from there (multiple stable versions, different kinds of stable versions - vandalism-free to peer-reviewed, etc.) will end up using its own table.
Should there be a new group of "stable version editors"? Should these be initially identical with admins to give it a kick-start? But that would already be covered with the code we have, right?
Don't forget to implement "oldid=stable" to return the stable revision. What if there's no stable revision? Return a blank page, a note, or just the current version?
Who's gonna see the stable version, if there is any? Anons, of course. What about the google bots? Probably the same. And new users? Yes, to prevent culture shock ;-) And add a user option to change that. Current users, however, should have the "show stable version by default" option turned /off/ by default to keep the current behaviour working. Least surprise, right?
Oh, and, of course, an additional dump with just the stable versions instead of the current ones. Also a "mixed" one, with stable version if existing, and current ones otherwise?
There should be a special page to list pages * with stable versions * without stable versions * pages with stable version, sorted by how much time/how many edits/mor many bytes are the difference between the stable and the current version
So much from Germany, and have fun at the last Wikimania day, Magnus
On 8/6/06, Magnus Manske magnus.manske@web.de wrote:
Who's gonna see the stable version, if there is any? Anons, of course. What about the google bots? Probably the same.
Google bots had better get exactly the same page as anons, if you don't want Wikipedia deindexed for cloaking. ;)
Regarding stable versions . . . could these be applied to non-articles as well? High-use templates are all full-protected, at least on enwiki, which is horribly anti-wiki: you have to discuss any but the most trivial changes for days, then get a sysop to institute them. It's impossible to be bold. A similar concept could be used in lieu of any protection, in fact (well, except the GFDL page and maybe main page, but including interface changes), given that a sysop has to approve the changes eventually, which would make the entire process much more wiki without actually reducing security. Too many people forget that protection is evil, and given that it seems largely unnecessary as well . . .
A related point is that in cases where this concept solely replaces protection against vandalism, it would be good to have delayed automatic approval, i.e., changes automatically go through if not reverted within a certain period. High-use templates could have edits frozen for a day or so to stop people from inserting penises into 70,000 pages at once or edit-warring and continually clearing the cache for no reason, while still allowing people to be bold and make changes, even anons.
On 8/6/06, Magnus Manske magnus.manske@web.de wrote:
Should there be a new group of "stable version editors"? Should these be initially identical with admins to give it a kick-start? But that would
Absolutely not - admins are appointed on the basis of their vandalism skills and trustworthiness, not on their knowledge of content. I would actually recommend a much broader set of users, like "everyone with the project for 3 months and with 250 edits" or something, and taking away those privileges liberally as needed.
Steve
Steve Bennett wrote:
On 8/6/06, Magnus Manske magnus.manske@web.de wrote:
Should there be a new group of "stable version editors"? Should these be initially identical with admins to give it a kick-start? But that would
Absolutely not - admins are appointed on the basis of their vandalism skills and trustworthiness, not on their knowledge of content.
Sure. That's why it currently needs an admin to edit [[MediaWiki:Common.css]] or [[template:cite book]] on en, right :)?
I would actually recommend a much broader set of users, like "everyone with the project for 3 months and with 250 edits" or something, and taking away those privileges liberally as needed.
Steve
On 8/7/06, Ligulem ligulem@pobox.com wrote:
Absolutely not - admins are appointed on the basis of their vandalism skills and trustworthiness, not on their knowledge of content.
Sure. That's why it currently needs an admin to edit [[MediaWiki:Common.css]] or [[template:cite book]] on en, right :)?
Yeah, it's a far from ideal situation. "Vandal fighters" definitely shouldn't be messing with the site-wide style sheets, and admins who primarily reorganise images and recover deletions shouldn't be banning or unbanning users. It's a problem.
Steve
Steve Bennett wrote:
On 8/7/06, Ligulem ligulem@pobox.com wrote:
Absolutely not - admins are appointed on the basis of their vandalism skills and trustworthiness, not on their knowledge of content.
Sure. That's why it currently needs an admin to edit [[MediaWiki:Common.css]] or [[template:cite book]] on en, right :)?
Yeah, it's a far from ideal situation. "Vandal fighters" definitely shouldn't be messing with the site-wide style sheets, and admins who primarily reorganise images and recover deletions shouldn't be banning or unbanning users. It's a problem.
The problem is rather the other way round: those that are trusted and knowledgeable to edit [[MediaWiki:Common.css]] or [[template:cite book]] shouldn't need to go requesting the whole set of admin tools (or an ambassador title, as someone put it on en :).
It's not a problem that those who have an "ambassador" title on en *are* allowed to edit [[MediaWiki:Common.css]]. Ambassadors usually are competent enough to recognize when they lack the skills needed to edit these pages. But they might be capable to delegate this due to their trust they own.
Maybe a finer access mechanism would be helpful here. For example an admin A should be able to give a user U the right to edit [[MediaWiki:Common.css]] specifically, because he "knows" that U is capable to do that and that A is capable to survey what's happening on [[MediaWiki:Common.css]] (site looks like shit after edit x of U, U has no reasonable explanation for his botch and A thus removes U's access right to edit [[MediaWiki:Common.css]]).
But this might rather be a wiki-political thing, which should be solved be the users and not by the devs. However, sometimes a bold developer action can solve a Gordian (wiki-)Knot.
For the moment, we could try once again using current capabilities of MediaWiki on en and split off some of the current "ambassador" tools into a new user group. The "protect" right might be a good starter to split off from "ambassador" :)
On 8/7/06, Ligulem ligulem@pobox.com wrote:
The problem is rather the other way round: those that are trusted and knowledgeable to edit [[MediaWiki:Common.css]] or [[template:cite book]] shouldn't need to go requesting the whole set of admin tools (or an ambassador title, as someone put it on en :).
Yes, certainly. The tools given to admins are pretty varied, and don't represent one specific role. You could group them like this:
Vandalism: Rollback, [un]banning, [un/semi]protection Page management: Moving special cases, deletion, undeletion (restoring old pages), renaming categories Site development: Modifying special pages like style sheets, skins etc Publishing: Modifying pages like main page which are Wikipeida's public face
The category of "page management" above could even be split to reflect the fact that being able to see old versions of ceratin pages involves a certain amount of trust due to confidential revisions being present...
What else am I missing? Is this a fair categorisation of the tools avaliable to admins?
Now, there are admins (on en) who have been knocked back for admin despite most people agreeing they would make good use of vandal fighting tools. Why? Because they weren't mature enough to handle the other roles.
Should we consider breaking up the "admin" role into these subroles and being more selective about what rights we give whom?
Steve
On 8/7/06, Steve Bennett stevage@gmail.com wrote:
Yes, certainly. The tools given to admins are pretty varied, and don't represent one specific role. You could group them like this:
[etc]
You know, only about three hours before you made that post, I independently wrote up a very similar proposal at http://en.wikipedia.org/wiki/Wikipedia:WikiProject_on_Adminship/a_la_carte. It's been rejected before, I think, but who knows, maybe now is the time . . .
wikitech-l@lists.wikimedia.org