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
Show replies by date
On 8/6/06, Magnus Manske <magnus.manske(a)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(a)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(a)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(a)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(a)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(a)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(a)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 . . .