Trying to reply to this thread in one message: On Sat, 2013-06-22 at 22:33 +0100, Alex Monk wrote: > I've just found out that WMF's Bugmeister Andre Klapper removed > "nearly everyone"'s Bugzilla adminship
Thanks for everybody's comments, and especially Sumana for quickly summarizing the situation while I was offline. There might be some misconception what "Bugzilla admin rights" means. "admin" sounds powerful, but in general Bugzilla admin rights are only required for a few rather uncommon actions. Also see http://blogs.gnome.org/aklapper/2013/05/28/understanding-bugzilla-groups-and-admin-rights The only *common* action that requires admin rights is editing permissions of other Bugzilla users [1], and this is definitely an area to reevaluate if things get worse, e.g. our reaction to spamming in Bugzilla. It might not be a good reason for more admins per se, but maybe for more admins in different timezones... :-) I tried to keep the policy short and simple: https://wikimediafoundation.org/wiki/Bugzilla_administrator_rights_policy Trying to work transparently, I also kept https://meta.wikimedia.org/w/index.php?title=System_administrators#List up-to-date (I kept Bugzilla users with "editusers" rights listed as admins [1], that's why there was a diff that Thehelpfulone corrected), and I mentioned the policy in my (nearly weekly) status updates [3], in an IRC office hour [4], and in monthly reports [5]. But it looks like I failed to recognize expectations on communicating this more widely because of the small number of currently affected people (~20) which I had contacted beforehand, and I ignored informing future Bugzilla admins out there which would also be affected by this. I'm sorry for that, it was (and still is) planned to announce this more widely, but I wasn't fast enough. :-/ So this is not about cutting out volunteers or so, as we have the same amount of Bugzilla admin volunteers as a few months ago. This is about giving people more fine-grained permissions for those tasks that they actually perform. The principle of least privilege. When ~30 people can change taxonomy or settings in Bugzilla like before, people do not always inform each other and sometimes duplicate efforts [2] and create inconsistency (e.g. adding subproject-specific but systemwide keywords). This is something to avoid, hence the policy. Version 4.2 of Bugzilla that we run now finally creates a log of taxonomy changes. It is planned to set up a cronjob to regularly inform me (and other admins interested) of changes that took place [6], as another backup source of information (it does not fully replace *discussing* the usefulness of a change first, though). I hope this covers most of the concerns. If you have more questions or if something is unclear, please don't hesitate to ask! Thanks, andre [1] Editing users requires "editusers" rights, but with "editusers" rights you can also edit your own account and make yourself an admin. [2] MediaWiki/Javascript component vs javascript keyword vs bug 2114, "newparser" keyword vs Parsoid product, "analytics" keyword vs. Analytics product, "newphp" keyword vs PHP4.x tracking bug 30092, "tracking" keyword vs tracking meta bug 2007, to mention a few still existing examples of missing coordination. [3] http://www.mediawiki.org/wiki/Bug_management/status [4] http://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_2013-05-13 [5] https://blog.wikimedia.org/2013/05/02/wikimedia-engineering-april-2013-report/ and https://blog.wikimedia.org/2013/06/10/wikimedia-engineering-may-2013-report/ [6] https://gerrit.wikimedia.org/r/#/c/56562/ -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
