The following request for comments is closed. There is sufficient support to implement the rewritten Meta–Steward Relationship document as policy. PeterSymonds (talk) 19:12, 2 February 2013 (UTC)
From the talk page:
- It draws a clear line between locally elected users and stewards, specially on CU/OS issues. Actually the Meta community has 7 CUs and 4 OSs to handle local CU/OS issues. It is rather reasonable to let those locally elected people to handle the local stuff while still allowing stewards to use those rights in emergencies or for cross-wiki checks/suppressions & staff/sysadmin people to use the tools for legal or technical reasons when needed.
- Reinforces the requirement for temporary administrators/other right requests to be community approved via the usual local procedure. We request to stop promoting people without following the procedures that this community spent time to design; unless the promotions are official or legal actions, or mandated by the Board, etc.
- And, most important, it allows stewards to perform a specific set of tasks for which they do not need to apply for local adminship but can use their global access at meta without problems and without local administrator flag. This will allow stewards using their administrative access at meta for obvious countervandalism such as vandal blocking, vandalism deletion and so on; leaving other tasks such as RfH requests for blocks and bans, RfD closures, user renames and the like to regular meta administrators.
I therefore invite you to express your opinion and propose changes to the proposed policy text as well to vote for or contra its approval in the vote that will be held later. Thanks. -- MarcoAurelio (talk) 11:18, 13 August 2012 (UTC)
- The community has been notified. -- MarcoAurelio (talk) 11:18, 13 August 2012 (UTC)
- Per talk, given the low level of discussion; I'm extending the discussion for a couple of weeks. -- MarcoAurelio (talk) 08:38, 29 August 2012 (UTC)
- I'll be advertising this RfC on Meta:Babel and Wikimedia Forum one last time. Let's see if we can get some more input. -- MarcoAurelio (talk) 15:15, 30 January 2013 (UTC)
- This phase starts today 13 August 2012 and ends at 10 september 2012. Please use === Three level headers === for each subject you want to discuss. Thanks.
Stewards and CentralNotice
I would suggest to explicitly allow stewards to edit CentralNotice in an uncontroversial way, such as updating the translation per request or fix apparent errors. Due to the high visibility of CentralNotice it is extremely important that we do not embarrase ourselves with errors, and update them as quick as possible. When people on other projects spot issues with CentralNotice and local admin cannot fix it (apparently), it also makes sense that they seek help from stewards. --Bencmq (talk) 13:18, 14 August 2012 (UTC)
- Most stewards already have local admin access to CentralNotice, I don't see how increasing the rights group to stewards will help. As it stands, there are many more admins than stewards, and most stewards already have admin rights locally, so the chances of a steward being around and no admin to update would be rare. It also requires certain familiarity with CentralNotice to change campaigns, someone might inadvertently end up breaking or affecting 700 wikis. There is already new infrastructure for translations, and stewards have a full-plate as it is without adding something that already works fine. Theo10011 (talk) 21:50, 18 August 2012 (UTC)
- Stewards do have the rights in their group to edit CentralNotice... --Bencmq (talk) 06:04, 19 August 2012 (UTC)
Stewards will avoid...
The proposed document mentions in a couple of places that stewards will "avoid" doing something. As an example, Stewards will avoid the use of their tools to create temporary administrators. I think this should be better of said as, if I am understanding the policy correctly (it's late so I may not be), that stewards will not use their tools.... The Helpful One 00:47, 19 August 2012 (UTC)
- Thanks - The point is of those is to say that if there's anybody here to do something, those localy elected will take care of the issue unless it is an emergency, a cross-wiki request, etc. Regards. -- MarcoAurelio (talk) 18:37, 19 August 2012 (UTC)
Stewards acting as crats in assigning permissions
In the strange event that after a week no local bureaucrat have determined the outcome nor explicity said they are working on determining one; a steward may close the discussion and implement the result based on Meta-Wiki's own policies and guidelines.
Can we see a time when there will be a necessity for stewards to act as local crats? I'm just thinking that we do currently have quite a significant number of crats, and there is not usually something that needs to be done urgently that waiting a few extra days over a week will harm, anything that requires urgent permissions is likely to be solved more quickly than 7 days, in the case of temporary adminships for example, this could be done in a few hours by poking one of our many locally appointed crats. The Helpful One 00:47, 19 August 2012 (UTC)
- I do agree that this seems not necessary. Stewards can close RfCs and such, but for flag requests, it seems unnecessary. I don't see how inactive crats on meta causes more damage than inactive crats on other projects (they all do, of course.)--Bencmq (talk) 06:06, 19 August 2012 (UTC)
- I'm glad to see people participating here :) - I don't think that stating what will be unavoidable if happened would hurt. That is already present in the current MSR policy. The point is to avoid what happens in other wikis: request stagnating and drama when a steward goes unblocking the situation. I agree that it seems rather unlikely nowadays that a steward has to act as local bureaucrat but I think it doesn't hurt either to clearly state this. Please note that if a request has been put "on hold" by a local bureaucrat it'll continue being on hold and this will not apply. I'm open to be persuaded on the time span though. -- MarcoAurelio (talk) 18:34, 19 August 2012 (UTC)
- Actually yes, it does hurt to state "exceptions": it's a way to make them "rules". So, please remove this part, there have already been objections to it and I don't understand why you're still insisting. --Nemo 07:26, 25 August 2012 (UTC)
- Actually the only objections come from you and WizardOfOz, the others commenting on the talk didn't said anything about it. I am not insisting. I am presenting the document to the community so they can discuss. If the community is not happy with that (and this section is for this) it will be removed. Accusing me to push something is something wrong. As I've said above, that phrase already exists in the current MSR page. -- MarcoAurelio (talk) 08:42, 25 August 2012 (UTC)
- I've no idea what you're talking about, there's nothing like that in the old text. As you're just "presenting the document to the community so they can discuss" and in a week here everyone agrees that this sentence is harmful, I'll remove it from the draft. Thanks, Nemo 06:45, 26 August 2012 (UTC)
- It was, but it was changed   without any discussion at all. -- MarcoAurelio (talk) 09:20, 26 August 2012 (UTC)
- It is still under discussion. Once it is removed, people can't read and voice their opinion.‴ Teles «Talk ˱@ L C S˲» 07:14, 26 August 2012 (UTC)
- How so? It's on this RfC, whose purpose is exactly to refine the draft before the vote. We could mark additions and removals by striking text or using colours if you prefer, go ahead if you think it's better for discussion as long as it's clear what's the most updated draft. --Nemo 08:18, 26 August 2012 (UTC)
In spite of having extended this discussion no further comments have been issued. If anybody has a proposal to make, please feel free. Would you add/remove/modify something from the draft? Regards. -- MarcoAurelio (talk) 07:53, 6 September 2012 (UTC)
A couple of late comments:
- "Should a local request for permissions close, it is requested to allow full seven days for the local bureaucrats to determine the outcome of the discussion." – Is this needed at all? I think it would be enough to just say that stewards who are not local bureaucrats will avoid using their tools to promote users when local crats are able to do so.
- I would change the section ordering a bit to make sure the most relevant cases are displayed first. Something like Administrative actions - Local promotions - Bot policy - Sensitive permissions - Logging of actions. Not a big deal either way, of course.
- I'm not aware of the stewards being technically able to perform unlogged actions here. I guess the Logging of actions section is there for the sysadmins specifically? Or is there some action that stewards can choose not to log on Meta, apart from the ones which are always unlogged (such as the unmerging of local accounts)?
Jafeluv (talk) 08:36, 6 September 2012 (UTC)
Thanks for your comments:
- Regarding point one and following #Stewards acting as crats in assigning permissions I agree with your proposed wording.
- Logging of actions: is in the original MSR and I think it was useful so I kept it. Since the word "steward" is a generic word for stewards, staff and sysadmin I bet this was intended to prevent direct and unlogged database changes.
-- MarcoAurelio (talk) 16:30, 6 September 2012 (UTC)
- I have no objections or further comments to this policy change. MBisanz talk 15:30, 27 September 2012 (UTC)
- I do not have any problems with the proposed policy change.--Ymblanter (talk) 15:39, 31 January 2013 (UTC)
- I've got no further comments nor objections to this draft. πr2 (t • c) 03:11, 1 February 2013 (UTC)
- Me neither. --MF-W 12:52, 1 February 2013 (UTC)
- As I said on the talk page, it seems fine to me - but there is one issue (about the seven day period, see talk) that should probably be resolved by somebody involved in that discussion. -Pete F (talk) 15:03, 1 February 2013 (UTC)
- MSR really needs some updating, so I have no objections to this proposed policy change. Pmlineditor (t · c · l) 18:35, 2 February 2013 (UTC)
Vote is being held at Requests for comment/Approval of the rewritten Meta-Steward relationship document as policy/Vote.