Talk:Limits to configuration changes

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search


Shouldn't this be at Technocracy? Who is to say "community consensus" means decisions by people who aren't sysadmins? There is a developer community too, and usually no one on-wiki bothers to ask them what they think, despite the fact that they have to do the work of implementing technical changes. Steven Walling (talk) 23:50, 15 September 2011 (UTC)

I don't think many people would interpret "community consensus" as anything but the most obvious sense of the phrase, but I don't have any objection to this page being moved to a better title.
These cases are specifically cases where there wasn't any real technical challenge that was unresolved. These requests could have been implemented with current technology, they simply weren't due community consensus (of the local projects) being ignored by system administrators.
System administrators and developers should weigh in on discussions like everyone else. And in some cases, it makes sense for individuals to place a higher value on their comments and votes. But I don't think many people would advocate a system that these (rare) cases demonstrate. I don't think many people favor a technocracy. --MZMcBride 02:56, 17 September 2011 (UTC)
Many people probably don't think much about what role "non-editing" groups should play in decisions, and are a bit shocked when they find out otherwise. Most members of the active editing community would expect that WMF, the devs, etc. will a) get involved in early discussions and b) implement the community decisions. The devs and WMF hear about these proposals via the same mechanisms as everyone else. The proposal at bugzilla:30208 has been raised almost every month at irc office hours; before, during and after. It has also been proposed on the strategy wiki, and discussed in March and May. The WMF have been invited to become involved in the formation of the proposal and consensus processes. Technical problems and resourcing issues are problems which should send proposals back to the drawing board. However that is not the case in the items listed on this page. These are political/ideology decisions being made by devs and WMF. Personally I think devs need a veto against the community consensus, but it should be limited to non-technical reasons, and the WMF should have a veto which is broad, but limited in a few ways to prevent them stonewalling the community entirely/indefinitely (e.g. the veto might be time limited to three months). John Vandenberg 04:43, 17 September 2011 (UTC)
Non-editing groups should realize that they are eminently replaceable and act accordingly. The technical talent we have is not special, after reading several interviews I can only assume that most of the foundation staff knows far less about Wikipedia than average user; it is the community of volunteers that is really our only valuble asset and should be heeded accordingly. The foundation was created because part time volunteers can't deal with legal issues or maintain servers very well, not to think for themselves. Extransit 02:46, 27 September 2011 (UTC)
You can assume lots of things. That doesn't make them true. ^demon 14:08, 27 September 2011 (UTC)
I think someone needs to check hisself before he wrecks hisself.--Jorm (WMF) 18:52, 27 September 2011 (UTC)
Are you being serious? Werdna 08:22, 27 September 2011 (UTC)

Global community[edit]

The title is quite POV or the content is not suitable for it: all the currently (three) listed requests were not only very controversial (which means consensus might be difficult to understand), but also affecting aspects shared by all the Wikimedia projects, which would require a broader consensus. Global community consensus (or lack of it) shouldn't be ignored. --Nemo 00:46, 16 September 2011 (UTC)

The title isn't great. It's a wiki and there's a move tab. :-) The community consensus in these cases was fairly clear. It usually is, particularly when it's quantifiable. I don't see how raising the autoconfirmed threshold on the English Wikipedia requires a "broader consensus." Among whom? Wiki projects are largely sovereign on issues like this. You really think the people at Swahili Wikinews need to have input as to whether it's 4 days or 7 days to edit certain pages on the English Wikipedia? I don't understand this. --MZMcBride 02:56, 17 September 2011 (UTC)
Regarding the title, this topic might fit within the movement roles work.
The only reason these are controversial is because they are community consensus on English Wikipedia, and the WMF has a large stake in anything to do with English Wikipedia. Other wikis dont have this problem. e.g. Arabic Wikipedia and several others have 50 edits for autoconfirmed. Farsi Wikipedia can easily have configuration changes for trial periods (see bugzilla:27195). WMF is really only impacted if the public and press don't like a change to the configuration of English Wikipedia. The flip-side is that Jimmy/WMF can force change without community consensus like they did during the w:Wikipedia biography controversy, and it was a lot of work to turn off Pending Changes after the trial. John Vandenberg 05:04, 17 September 2011 (UTC)
Yes, as I said on bugzilla I think that there are limits to what local consensus can change, because Wikipedia (as the other Wikimedia projects) is still a unified project, with language editions and local differences which can be important but will have some limit. There are some changes that would change how Wikipedia can be defined and described, especially if they're applied to the English Wikipedia (because all kinds of media often copy English ones, to start with), and can't be decided by the local community alone.
Some "technical" configurations are in fact implicit global policies, even if they're not written in a recognized Meta page or WMF board resolution and they have some flexibility. Everyone seems to agree that no Wikimedia project is allowed to restrict anonymous users from editing, for instance. Restricting createpage right to autoconfirmed is less clear an issue, but it makes sense to imagine that it falls in this category. With regard to the other examples: yes, I think that restricting page creation to registered users in a panic has been an error and that those limits for autoconfirmed status are absurd and should have been discussed more; but this proves only that the WMF can be wrong and that it cares less about small wikis and their errors (what a surprise!), not that we're all bound to make more and more bigger errors.
Finally, based on this comment I propose Limits to configuration changes as title for now; everyone is free to move again, naturally. --Nemo 12:56, 17 September 2011 (UTC)
I like the new title. Is there a Wikipedia page like oldwikisource:WS:COORD, which is a table of differences between the language subdomains of Wikisource? John Vandenberg 13:27, 17 September 2011 (UTC)
I don't think so, but it would certainly be interesting. --MZMcBride 14:31, 17 September 2011 (UTC)
We have some such pages in Category:Wikimedia projects coordination, we certainly need more. Nemo 09:30, 3 October 2011 (UTC)
Nemo: I think the new title is better. Not perfect, but better. Thanks. :-)
Regarding when it's okay to say no, I can certainly agree that there are defining principles that can't be ignored when implementing configuration changes. First and foremost, the code has to be secure, scalable, and sane. Beyond that, it has to fit in to Wikimedia's core values. Proposals to allow inline images from anywhere on the web would be problematic. A proposal to lock down the site from anonymous editors would be (and has been) problematic.
Sometimes developers/system administrators have a tendency to simply "hold out" on certain changes. For years, |link= wasn't allowed in image syntax because of largely imaginary copyright/attribution concerns. Eventually hacks were created using ImageMap and other tools and finally the syntax was implemented by Tim Starling. This isn't quite a configuration change, so it wouldn't be listed on this page, but it is a demonstration of a similar (if not the same) underlying problem, I think. --MZMcBride 14:31, 17 September 2011 (UTC)

Just noting[edit]

I'd like to list the following config changes that enwiki filed that have been done. 12190, 13498, 13890, 14075, 16552--that was just skimming Site Requests for comments that contained '', there's plenty more. That's also not counting the many dozens of feature requests that have originated from enwiki and been implemented. ^demon 14:04, 27 September 2011 (UTC)

w:Man bites dog (journalism) --MZMcBride 17:14, 7 October 2011 (UTC)

Added similar one from id.wp[edit] Bennylin 05:43, 5 October 2011 (UTC)

The community, God love it, is *frequently* on crack, and needs to be told "just no." David Gerard

If he'll spew crap like that, I'm going to be very blunt and tell David Gerard that he should stop doing PCP; the fact that we can produce evidence to back our position up and they can't should demonstrate that we actually know what we're doing and they don't but think they do. The Blade of the Northern Lights (話して下さい) 20:30, 6 October 2011 (UTC)

Disconnection from stewards overseeing[edit]

Meta used to be the only project where bureaucrats were allowed to remove sysop and bureaucrat rights, a quite obvious exception given the tight connection between the Meta community and stewards. Lately, for unknown reasons, some projects are being allowed to disconnect themselves from the stewards' (loose) overseeing of such deflags. There's no need to discuss here how useful such an overseeing is: but I think that, if projects are allowed to request so-called "super bureaucrats", there must be a global discussion to decide which projects can request it, we can't just proceed randomly or allow everyone to opt-out. (My personal opinion is that no project should be allowed to do so; even Meta could live without it.) What's the way to proceed, a RfC? Note that this question is prompted by the observation of a peak of such requests, the next one being in two weeks from now. Nemo 13:25, 23 February 2012 (UTC)

I agree, specially on the part that projects (included meta) could live without this and that no project should be allowed to do so. It breaks the beneficious external oversight and it even breaks more the central rights log, which for years used to be the place to look for rights removals at any project. —Marco Aurelio (Nihil Prius Fide) 16:58, 6 March 2012 (UTC)
Note: there's a list on Bureaucrat#Removing access. I've not verified its completeness and accuracy, but apparently several mistakes happened about such special permissions given to bureaucrats. Nemo 10:42, 12 March 2012 (UTC)
Cf. Bug 35258 – Allow bureaucrats to remove sysop rights on fr.wikipedia. Nemo 12:05, 16 March 2012 (UTC)
I agree as well, administrators shouldn't be locally removeable, especially on wikis with only one or two (active) crats. And of course, removing crat flag locally is an absolut "no-go"! a×pdeHello! 13:03, 16 March 2012 (UTC)
I disagree. A bit of an explanation : I'm a bureaucrat on fr.wp (so yes, kinda biaised), and we just concluded a RfC there which showed overwhelming support (82% is good, right ?) for this right (desysop) to be given to all bureaucrats. The rationale being that :
  • It makes it unnecessarily difficult for sysop to request the removal of their rights (some don't speek inglishe, some don't want to go outside fr.wp for something they feel don't concern anyone outside fr.wp - example : fr:User:Aristote2, who asked the bureaucrats for the removal of his sysop rights)
  • It doesn't prevent abuse, but makes it harder for the people concerned to complain (example : User:Hégésippe Cormier, who briefly lost his sysop rights due to the haste of user:Yann - a steward). Again, it makes it difficult for someone who's not good in English to complain - where, to who, how ?
  • It makes it harder for the local community to see the user changes. What MarcoAurelio see as a disadvantage (breaking the central rights log), many if not all on fr.wp saw as an advantage : finally, we could see the removal of the sysop rights on the same log as the granting of such rights. We see block and unblock, protect and unprotect, delete and undelete on the same logs, right ? Why not addition and removal of the sysop rights, like for the botflag ? Many find that counterintuitive.
  • It's more "paperwork" (and it's not so rare : with the removal of the rights for inactivity on fr.wp, the occasional temporary sysop, and the wikibreaks, that's about one or two a month).
Now, I'm not saying it should be given to any wiki, with no oversight by anybody and all, but there are 8 bureaucrats and nearly 200 sysops on fr.wp. Any "abuse" would be reported to meta within a day at most (within an hour, more probably). And any right with legal consequences (i.e., checkuser and oversight rights) remains under the control of the steward, and rightly so.
en.wp has been granted this technical possibility over 6 months ago : why block it for fr.wp while there is further discussion about it here ? If the discussion on meta concludes to the removal of this possibility for all wikis, so be it, but I find it unfair for fr.wp that our request to bugzilla should be blocked due to circumstantial distrust. Esprit Fugace (talk) 18:03, 16 March 2012 (UTC)
Your points are useful and well-known, but do not bring water to your conclusion. If there's some difficulty of interaction with stewards, this is the real problem, not who holds the rights; you don't seem to have considered any other option. Also, if even big wikis like have sysops who don't know about the stewards and so on, I can't imagine how confusing the system can be for small wikis: both categories would deserve an improvement, which doesn't come from raising walls.
The discussion on this page is only about the fact that some criteria are needed; yes, so far we've not had any clear rule, but very few wikis requested an exception, while currently this is becoming a problem. I'm not saying that or shouldn't have this right, but this should be considered in perspective and globally. What you've said above would be best put in an RfC to discuss the matter: just add why other options are not considered viable and on what basis should be allowed an exception (with clear criteria), and you're done, making a good service to all other wikis. Stewards will love to know how to serve wikis better, I'm sure. Cheers, Nemo 18:34, 16 March 2012 (UTC)
Then why don't you try launching such a RfC ? You're the one who wants a change to what's been done 'till now... Esprit Fugace (talk) 18:42, 16 March 2012 (UTC)
I don't think so. The exceptions are exceptions. Had I to open an RfC, I'd just explain why there's no reason to remove flags locally and the RfC would start with the proposal of removing such a permission from all wikis. You know why you want this, I don't. If you start the RfC, we can focus it on what's the perceived need and how to achieve it. Nemo 20:36, 16 March 2012 (UTC)
If i remember it well, stewards were create to respond to the need of bureaucratic task for small wiki and then their roles were expanded. Removing rights was a bureaucratic task long time ago, isn't it ? I don't think that adding rights could be done by bureaucrat and now then couldn't remove it, and a majority of user think so on WP:FR. The only reason is to have a "power separation". It could be normal but that not the thinking of french community. The execption on WP:EN could also be done for WP:FR. Nobody ask to give the right to remove right for all bureaucrats on all communities the hindi case show that isn't a good idea. A counterpart to this request is to give to steward more time to respond to other communities, it's nbot bad ? So please simply accept this request. It would not be burried in the marble, if anything goes wrong a roollback could be done... --Gdgourou (talk) 23:49, 17 March 2012 (UTC)
You don't remember well. See Wikipedia power structure for some history. Nemo 22:27, 18 March 2012 (UTC)

Here is a list of open requests to make this change:

Just for the sake of tracking. At this point, someone with an opinion should probably make an RfC. ST47 (talk) 07:03, 18 March 2012 (UTC)

I believe that any project should be allowed to remove the admin flags locally. There is really no need to wait for a steward to do this. The reason this popped up is some abuse that took place on hi.wp, so you just jumped to the conclusion that this could happen anywhere, which is false. But even if some 'crat would decide to revoke all the sysops, this could easily be reverted by stewards. The real problem on seemed to be the deletion of many articles, but this is totally unrelated to the problem of sysop revocation, and if anything, an argument in favour of the break-up from stewards. Any sysop could decide to provoke chaos by running a robot which deletes pages, and having a local bureaucrat to revoke the sysop's rights would make it much easier to stop this.
I see this issue as an unneeded control that the Foundation has on the individual projects; from the moment a project had a bureaucrat appointed, the steward should become only a back-up method of appointing and revoking user rights.--Strainu (talk) 11:22, 18 March 2012 (UTC)

I find this all a bit perplexing; a rogue bureaucrat removing userrights wrongly is a very rare scenario, and the argument that stewards are available 24/7 to deal with userrights issues applies to that rare scenario too - so it's illogical to insist that stewards must handle desysopping. Handing out userrights is far more dangerous, and we allow that locally. So if a community (on a wiki large enough that "community" is a meangful term) wants local desysopping, let 'em have it. Anyway, the argument about stewards "overseeing" seems to imply a rather different relationship between stewards and large projects than we are familiar with. Rd232 (talk) 12:51, 20 March 2012 (UTC)

Desysop is not done locally to prevent the most severe wheel warring, it's very simple. Local deflag puts some sysops above others in conflicts about sysops, it's self-evident. And it's the same reason why sysop have unblockself right by default. Nemo 18:27, 22 March 2012 (UTC)
Desysop is not done locally to prevent the most severe wheel warring - that seems desperate, frankly. Wheelwars between bureaucrats over whether someone should be desysopped or not? Just doesn't seem likely. And aren't people always saying that stewards are available 24/7? Why doesn't that apply to removing bits from warring or rogue bureaucrats? Rd232 (talk) 18:03, 23 March 2012 (UTC)
Desperate, really? Where do you live? I've already seen it happening, and very recently. So you don't agree that the technical parity among sysops is one of the main characteristics of MediaWiki (defaults) and Wikimedia projects? Looks really weird, especially for you. Nemo 13:55, 24 March 2012 (UTC)
? Sysops are not bureaucrats. We're talking about giving bureaucrats the right to desysop (on projects that want it). And you didn't answer my question. Rd232 (talk) 21:00, 24 March 2012 (UTC)
Bureaucrats are usually also sysops. Super-bureaucrats become super-sysops because they have the technical ability to desysop the others and win any wheel-war. One doesn't need to actually use such a power to impose it. Your question isn't relevant: blatant abuse is not the point (that can be easily spotted and reverted), the point is the change in the "power structure", which might be harmless or even beneficial, but needs discussion and some criteria. Nemo 21:46, 24 March 2012 (UTC)
they have the technical ability to desysop the others and win any wheel-war - desysopping is a radical measure; a user desysopped without good cause will complain about it, and the bureaucrat may lose their bit. A bureaucrat must know that desysopping to end a wheel-war can only be a temporary measure, if the desysopping is not justified. needs discussion and some criteria - that's up to the local community, isn't it? The only caveat I would accept is that for wikis so small that "the community" is very small or non-existent, then a request to enable local desysopping might be denied. Rd232 (talk) 10:58, 25 March 2012 (UTC)
Per Nemo above, completly. That just happened recently, some months ago, in my (former) homewiki. Emergency desysop had to be requested as blocks to other admins and users started going on. Better that I don't guess what would have happened if the ability to desysop were given to those people, given that administrators there are given bureaucrat access too by default; and that threats to desysop were made. —Marco Aurelio (Nihil Prius Fide) 17:29, 24 March 2012 (UTC)
"Better that I don't guess what would have happened if the ability to desysop were given to those people" - then some people might have been desysopped. Boo hoo (it's eminently fixable). But anyway, the right to desysop is not to be given to bureaucrats on every project; it's to be given to bureaucrats on projects that have community consensus for it. Rd232 (talk) 21:00, 24 March 2012 (UTC)
Doesn't change the point. The point is that there's a reason not to deflag locally, although one can disagree, and that it's not a characteristic which can be dropped without some criteria. Nemo 21:46, 24 March 2012 (UTC)

Date column[edit]

I think it would be useful to add a date column, for when the initial request was made based on apparent project consensus. For configuration changes which were rejected on many wikis, the date of the first would be the most useful, but hopefully additional dates for the other projects can be added without breaking the sortability of the table. John Vandenberg (talk) 06:29, 24 August 2014 (UTC)