For a week or so stewards have a new toy which became a very hot potato. We got it mysteriously (at least for me; while I may guess how did we get it), some of stewards started with tests, but, generally, to be honest, we don't have a clue what to do with that. Actually, some of us have some clue, some of us started with a very lite usage of that (we need help from SWMT [1] members, so some of us thought that it would be useful to give global rollback permission to them; however, the group is removed after two or three days because we don't have consensus about this).

So, there are global groups and they are documented at Stewards handbook [2]. As you are *not* able to see [3], there are a lot of interesting privileges [A1] and we (the community) need to start a discussion how to use them.

The other fact is that stewards are now sysops at all projects. This is, of course, very useful, because we don't need to become sysops for every action and some of stewards are using admin rights at small wikis at daily basis (usually, blocking spammers). Stewards are, also, doubtful about having global CheckUser and Oversight rights and there is no consensus about giving to ourselves such permissions. One group thinks that we are not allowed to have global CU rights, while other group think that we are able to have them, but we are not able to use them at projects which have their own CUs. I agree with both statements, while I prefer to treat those rights as purely technical, but we have some technical problems with treating those rights as technical, too :) So, yes, we are humans and we have our own doubts.

As I said, this is a hot potato which we got mysteriously. No one of the Board members said anything to us, as well as we didn't get any input from the WMF staff (except one not so significant Carry's question). As this is a *huge* change, I am willing to think that they are reading our emails and looking what should we do next. And I am sure that the situation is a little bit funny to them; as well as it is to me :)

The most important part of the implementation of the global groups is, of course, a possibility to make a fine adjustments of *global* permissions. At the [A1] you may see that all of the permissions are equal to the local ones. This means that we are able to make global admins, global bureaucrats, global checkusers as well as a global mix of the permissions (or, better, some new global groups which would fit better for a particular purpose).

I have some ideas how to make this or that, but I think that it is too early to talk about that. First of all, you should know what is going on and to discuss about the fact that we (the community) have something new -- good or bad (I think that this is a good thing) -- which we probably got from some extraterrestrial form of life.

== A1 ==

The list of global permissions are below.

* Use higher limits in API queries * Edit semi-protected pages * Have one's own edits automatically marked as patrolled * Delete pages with large histories * Block other users from editing * Block a user from sending email * Administer elections * Be treated as an automated process * Search deleted pages * Administrate global accounts * Merge their account * Check user's IP addresses and other information * Create new user accounts * Create pages (which are not discussion pages) * Create discussion pages * Delete pages * View deleted history entries, without their associated text * Edit pages * Edit the user interface * Edit other users' CSS and JS files * Edit membership to global groups * Manage global groups * Review and restore revisions hidden from Sysops * Import pages from other wikis * Import pages from a file upload * Bypass IP blocks, auto-blocks and range blocks * Grant and revoke bot flags * Make users into sysops or bureaucrats * Mark rolled-back edits as bot edits * Mark edits as minor * Move pages * Not have minor edits to discussion pages trigger the new messages prompt * nuke * Override the spoofing checks * View a previously hidden revision * Mark others' edits as patrolled * Change protection levels and edit protected pages * Bypass automatic blocks of proxies * Purge the site cache for a page without confirmation * Read pages * Rename users * Overwrite an existing file * Override files on the shared media repository locally * Quickly rollback the edits of the last user who edited a particular page * Perform captcha triggering actions without having to go through the captcha * Not create a redirect from the old name when moving a page * Override the title blacklist * Submit a trackback * Override the username blacklist * Undelete a page * View a list of unwatched pages * Upload files * Upload a file from a URL address * Edit all user rights

== Links == [1] - Small wiki monitoring team: http://meta.wikimedia.org/wiki/Small_Wiki_Monitoring_Team [2] - http://meta.wikimedia.org/wiki/Steward_handbook#Adjusting_global_groups_.26_... [3] - The example is the list of the stewards' permissions: http://meta.wikimedia.org/wiki/Special:GlobalGroupPermissions/steward