Wikipedia talk:Global rights policy/Archive 1
This is an archive of past discussions about Wikipedia:Global rights policy. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 |
Proposed
Comments much appreciated. See relevant discussions at Wikipedia_talk:Administrators#New_global_userright and Wikipedia:Village_pump_(policy)#Rollback_for_stewards. Daniel (talk) 01:29, 7 June 2008 (UTC)
- Since you added the IRC link, I fully support this proposal. MBisanz talk 01:52, 7 June 2008 (UTC)
- I also endorse this. I can see it being slightly redundant with the opt-out section at meta concerning AVFs, but having a clear statement here concerning our practice is probably the best way to do things. Sephiroth BCR (Converse) 02:26, 7 June 2008 (UTC)
Using rollback on enwiki
"This includes rollback — AVF's must request and be granted the right locally, and should it be removed or not granted, they are not allowed to use rollback on this wiki."
Why? — Werdna talk 09:03, 7 June 2008 (UTC)
- The next sentence explains. Daniel (talk) 09:34, 7 June 2008 (UTC)
- "Rather than interfering with the global AVF applications process at Meta to enforce local standards of user rights, the English Wikipedia community would rather be autonomous with regards to rollback (and all other) rights usage.". Sounds like a load of nonsense to me, to be honest. These anti-vandal-fighters can already revert edits using undo, or with twinkle, or with some other software tool, or, heaven forbid, using a manual reversion. In my capacity as a meta administrator, I frequently work on the spam blacklist — and this often requires reverting some link addition on 20+ wikis. It is unreasonable to expect me to consult a little table or something to figure out if I'm allowed to use rollback for each link (currently, I use undo, and, since I just click on each diff link, and click on where I know the undo link to be, I don't really pay any attention to what wiki I'm on). I don't understand that the justification here outweighs the benefits of requiring 20 clicks to revert this spamming, rather than 40. — Werdna talk 11:00, 7 June 2008 (UTC)
- What if an AVF has had their rollback removed with prejudice before being granted AVF tools? They're all of a sudden allowed to override the local community consensus? That was the idea of the proposal. Furthermore, what happens if/when someone abuses rollback (to the point where, if it was granted locally, it'd be revoked)? Under your proposal, the English Wikipedia could not prohibit its use here even if it would otherwise be disallowed. Daniel (talk) 11:05, 7 June 2008 (UTC)
- After discussing the merits of various angles to take on this issue with Werdna and other administrators, I spat out this, which seems to be more along a compromise line of thinking. Thoughts much appreciated. Daniel (talk) 11:21, 7 June 2008 (UTC)
- Much preferred, thank you. It represents a good compromise between protecting English Wikipedia consensus from being overridden from a comparably smaller outside consensus or bureaucracy, and reducing bureaucracy for those who need a streamlined process for global administration. — Werdna talk 11:24, 7 June 2008 (UTC)
- It's just about there, if Rollback has been refused, or has been granted and removed, then the person shouldn't be using the Rollback function, but I think a block for edit warring in the past 90 days would also rule out the use of the Rollback tool. Anything older than 90 days would be fine with me, and it's usually fine at RfA, unless it's repeated. I've said this already, but we shouldn't be writing policy to stop people unsuited such roles from doing damage, we should be stopping these unsuited users from ever being given access to these tools in the first instance. I would therefore like to see a link to the voting at Meta for these roles included in the list at WP:RFA. Nick (talk) 11:29, 7 June 2008 (UTC)
- 90 days sounds like a good idea - the comparison you draw with the general time lapse at enwp RfA is very relevant. I've boldly added it to the proposal.
- About listing requests at RfA, I would suggest that such a discussion may be better served until after this proposal is finalised and/or accepted as policy. There would possibly be issues regarding selection bias if we listed it at RfA itself, but I certainly agree that having requested listed somewhere locally would be a good idea. We could even consider having a bot update a section on this page, which would only be watched by those interested in the global rights thing rather than RfA in general. Also, because AVF's can't use administrator-specific tools, RfA may not be exactly the right venue. But I certainly agree with the principle. Daniel (talk) 11:33, 7 June 2008 (UTC)
I can support this version. Lets see if it causes any problems in practice. Yechiel (Shalom) 04:44, 8 June 2008 (UTC)
I disagree with this proposal as overly bureaucratic and lacking AGF. AVF's are to be elected from the number of experienced users, already having sysop access on one, usually more projects. They will be experienced with cross-wiki issues and re expected to be sane enough to treat rollback appropriately even without reading the letter of local policy. So, these people are one of those who get rollback easily here, regardless of amount of their contributions. So, requiring them to request +rollback explicitly is nothing but instruction creep, and instruction creep should burn in hell. MaxSem(Han shot first!) 07:31, 9 June 2008 (UTC)
- They don't have to request rollback. The only case where they would is if they use it improperly and only after that fact do they have to request it from an administrator. Sephiroth BCR (Converse) 07:57, 9 June 2008 (UTC)
- Indeed. I don't think any part of MaxSem's objection applies to the proposal as written. Daniel (talk) 13:49, 9 June 2008 (UTC)
- Right, I misread some things. MaxSem(Han shot first!) 13:53, 9 June 2008 (UTC)
- Indeed. I don't think any part of MaxSem's objection applies to the proposal as written. Daniel (talk) 13:49, 9 June 2008 (UTC)
Watching deleted edits for AVFs
I think that there is no sense to forbid that to AVFs because it is not possible to monitor such actions. --millosh (talk (meta:)) 14:06, 7 June 2008 (UTC)
- That's something that would be exceptionally useful for any Commons administrators and editors who are looking for source, copyright and file information when dealing with images moved onto Commons. I would certainly support any user who is accessing deleted revisions to deal with Commons copyright issues, and in the many other areas too where such access would be useful, I would generally support the accessing of deleted revisions. Nick (talk) 14:34, 7 June 2008 (UTC)
- One issues would be that en-wp has adopted oversight only for release of personal information (as per foundation policy). We would need to be very specific with AVFs that they may not release deleted material concerning BLPs, copyvios, etc. MBisanz talk 23:16, 7 June 2008 (UTC)
- Yes, it should be defined inside of the documents related to AVFs. Maybe you may here define the policy which would be transferred to Meta? --millosh (talk (meta:)) 03:54, 9 June 2008 (UTC)
- One issues would be that en-wp has adopted oversight only for release of personal information (as per foundation policy). We would need to be very specific with AVFs that they may not release deleted material concerning BLPs, copyvios, etc. MBisanz talk 23:16, 7 June 2008 (UTC)
Describing stewards' permissions
I think that it should be mentioned that stewards are giving CU and OS permissions (when asked by en.wp community) and removing all permissions (when asked by en.wp community or the Board). --millosh (talk (meta:)) 14:09, 7 June 2008 (UTC)
- The English Wikipedia community cannot grant CU or OS permissions; only the Arbitration Committee can. It can also not revoke it; only the Committee or the Board can, as well. Daniel (talk) 03:07, 9 June 2008 (UTC)
Red tape
Frankly, I see too much of it here. One question I have is, does this interfere with the rollback system we have in place? — scetoaux (T|C) 02:24, 10 June 2008 (UTC)
- Not that I can see. The only case in which our rollback system becomes involved is if an AVF misuses rollback and then has to request the +rollback bit directly from an administrator. Aside from that, there's no interaction with our rollback process. Sephiroth BCR (Converse) 04:20, 10 June 2008 (UTC)
Seems fine
This seems fairly uncontroversial and agreeable. Happy to support. Stifle (talk) 13:31, 10 June 2008 (UTC)
Agreed, this seems to be a sensible proposal. Davewild (talk) 20:45, 10 June 2008 (UTC)
Part with stewards role
I described stewards role toward granting and revoking permissions. --millosh (talk (meta:)) 04:10, 11 June 2008 (UTC)
Deleted contributions
Are the words "Global sysops found to be using their global permissions to access and disseminate such materials" intended to be understood to mean that global sysops are not permitted mere *access* to these deleted revisions, or does it mean they may access so long as they do not disseminate? Since tool-powered dissemination requires access, I'd recommend one of the words "access" or "disseminate" be removed for clarity. I'd also recommend against denying access, because it may not be clear if a piece of deleted information falls into that category prior to accessing it, and viewing some of these classes of info could be essential to cross-wiki problem solving. If there are no objections here I'll strike access from the quoted text. --Gmaxwell (talk) 13:10, 13 June 2008 (UTC)
- Greg, I am rather unskilled at the technical terms, so yes, please change it to whatever means "Global sysops can't give other people copies of these types of deleted contribs." :) MBisanz talk 20:00, 13 June 2008 (UTC)
Commons proposal
As this is a proposed global right, I draw attention to commons:Commons:Administrators' noticeboard#Viewdeleted on other projects. giggy (:O) 10:02, 16 June 2008 (UTC)
Voting rights
Seeing at en.wp editors' voting rights in future polls on Global Sysops are being questioned at m:Talk:Global_sysops#One_more_idea and under the current proposal, abuse at en.wiki will not result in automatic de-global sysopping, only local blocking with the hope they won't unblock themselves, I would urge a more proactive bent towards this policy, possibly preventively blocking global sysops at en.wp and requiring them to have alternate non-global sysop accounts for editing here. MBisanz talk 03:55, 19 June 2008 (UTC)
- Utterly pointless, apparent petty retalliation for equally petty politicking on meta. — Werdna talk
- To the end of being over-prepared, and well we all know my tendency towards pointlessness, I've created User:MBisanz/GSBlock. MBisanz talk 20:55, 19 June 2008 (UTC)
- I don't think that would work. If a technical measure is desired to stop admin rights being used on en.wiki, blocking is not a good solution, as it would inevitably generate controversy and ill-will between people. Also, if a global admin did want to go rouge and use their tools on en.wiki, they could easily unblock themselves. Tra (Talk) 21:37, 19 June 2008 (UTC)
- Yes, that second issue, of global sysops being able to unblock themselves, and the weak assurances from Meta on desysopping global users who abuse their rights (I think the current response is "block them locally unless it is really egregious"), is concerning and I'm investigating technical means to lessen that issue (auto-reblocking bots, etc). On the other hand, if Meta is going to say "en.wiki users can't vote on something that will put them at risk unless they agree with us", I don't see any reason to assume a lot of good faith going into the discussion. MBisanz talk 21:45, 19 June 2008 (UTC)
- Regardless of any disagreements between projects, global admins would be elected based on trust and experience so I would hope that the vast majority would use good faith and know when they should and should not use the tools. I don't think auto-reblocking bots would work as a) the admin could just run an auto-unblocking bot and b) I'm not sure the community would support that kind of bot. I think the best way to restrict where the tools apply is to code the software to allow the granting of rights to a specific group of wikis, in this case, the small wikis. The only problem with that is it may take a while to be coded. Tra (Talk) 22:35, 19 June 2008 (UTC)
- Yea, I'd fully support the idea with technical restrictions. My fear is that if the proposal is approved before they are created and implmented, well the lack of drama would shove them to the back burner and they'd be coded around 2020. And yes, it would be interesting to see 2 blocking/unblocking bots go at it, our bot ops can get their bots up to ~700-1000 edits per minute, so it would certainly create some interesting logs. :) MBisanz talk 23:14, 19 June 2008 (UTC)
- Regardless of any disagreements between projects, global admins would be elected based on trust and experience so I would hope that the vast majority would use good faith and know when they should and should not use the tools. I don't think auto-reblocking bots would work as a) the admin could just run an auto-unblocking bot and b) I'm not sure the community would support that kind of bot. I think the best way to restrict where the tools apply is to code the software to allow the granting of rights to a specific group of wikis, in this case, the small wikis. The only problem with that is it may take a while to be coded. Tra (Talk) 22:35, 19 June 2008 (UTC)
- Yes, that second issue, of global sysops being able to unblock themselves, and the weak assurances from Meta on desysopping global users who abuse their rights (I think the current response is "block them locally unless it is really egregious"), is concerning and I'm investigating technical means to lessen that issue (auto-reblocking bots, etc). On the other hand, if Meta is going to say "en.wiki users can't vote on something that will put them at risk unless they agree with us", I don't see any reason to assume a lot of good faith going into the discussion. MBisanz talk 21:45, 19 June 2008 (UTC)
- I don't think that would work. If a technical measure is desired to stop admin rights being used on en.wiki, blocking is not a good solution, as it would inevitably generate controversy and ill-will between people. Also, if a global admin did want to go rouge and use their tools on en.wiki, they could easily unblock themselves. Tra (Talk) 21:37, 19 June 2008 (UTC)
- To the end of being over-prepared, and well we all know my tendency towards pointlessness, I've created User:MBisanz/GSBlock. MBisanz talk 20:55, 19 June 2008 (UTC)
There are not going to be bot blocking/unblocking wars. There is not going to be automatic blocks on sight of global sysops, and there will most certainly not be restrictions on who can vote on particular pieces of functionality. Can we all please calm down? I may implement wiki sets for global groups at some stage in the future, but my time is limited, and I am currently focussing on my AbuseFilter extension. — Werdna talk 08:05, 20 June 2008 (UTC)
- Sets of wikis have been implemented. The "Global Sysop" right could be renamed (for political purposes) to "Additional Sysops" or something if it'd make larger projects happy, but without enwiki opt-in, they'd simply be another non-admin user here (unless they were already a regular admin). Kylu (talk) 23:49, 2 August 2008 (UTC)
Global bots
Over at meta, they have created a m:Global_bots#Global_bots for global bots. They have a policy list of all wikis at m:Bot_policy/Implementation#Where_it_is_policy. I think we should update our local Bot and GRU policies to reflect that global bots may only operate at en.wp with the approval of the en.wp BAG. Anyone care to do the wordsmithing? MBisanz talk 02:03, 29 July 2008 (UTC)
- I don't get it - we currently request BAG approval, so adding ourselves to the global bot list will make no sense. As per this we shouldn't need to request BAG approval. —Giggy 06:15, 3 August 2008 (UTC)
- Unnecessary, I think. The Global bot policy is a mere extension of the Meta bot policy, meaning it only applies to those project which opt-in. The current bot policy covers this, as the global bot flag does not apply to this project unless we opt-in (in which case they're approved bots by policy in any case), and adding more verbiage would only assist instruction creep. (I think Giggy and I may be setting the record for most edit conflicts on multiple projects in one day...) Kylu (talk) 06:18, 3 August 2008 (UTC)
Move proposal
I propose this be moved to Wikipedia:Global rights policy. —Anonymous DissidentTalk 07:47, 25 September 2008 (UTC)
- I agree, I created this when global userrights was less developed. MBisanz talk 23:17, 9 March 2009 (UTC)
Steward intervention
In light of Wikipedia:Bureaucrats'_noticeboard#Urgent:_vandal_with_an_unblockable_name, I am proposing we edit the #Steward section of this policy to make it clear that Stewards can and should intervene in emergencies at enwiki where there is no local user active at the time to handle the emergency. MBisanz talk 23:17, 9 March 2009 (UTC)
- Ok, changed. MBisanz talk 01:25, 10 March 2009 (UTC)
- I'd assumed that was the case anyway, but it's nice to have it clarified. Angela. 02:57, 10 March 2009 (UTC)
New consensus needed
This policy gained fairly rough consensus last summer to allow Global Sysops to act as rollbackers and view some deleted contributions only. Steward Pathoschild recently partially rewrote m:Global sysops; Global Sysop policies must now be reexamined on every project. I cleaned up ours a little; global sysops here are now only allowed to use rollback and in extremely rare cases, use other rights as well. I just wanted to know if people still felt that the policy was good enough. NuclearWarfare (Talk) 00:39, 29 March 2009 (UTC)
- Do you have a link to the 'rough consensus'? I've noticed that you've edited the policy to prohibit global sysops from accessing deleted materials. I'm not sure if this is a good thing - deleted materials may perhaps need to be viewed in order to investigate some cross-wiki issues. Also, looking at the way it reads now, it might be simpler to just opt out en-wiki entirely from the global sysop system, and only allow global rollbackers. Tra (Talk) 01:06, 29 March 2009 (UTC)
- I've switched back to the old Deleted Contributions section for now. NuclearWarfare (Talk) 01:17, 29 March 2009 (UTC)
- Opting out enwiki automatically shuts out global sysops from acting in situations where no English Wikipedia administrator can be found, as they simply do not have the access level to act unless they are placed on an opt-in list. As for rough consensus, I was going by the fact that people were proposing changes and debating it for a while now on this talk page, but it still stayed in. NuclearWarfare (Talk) 01:17, 29 March 2009 (UTC)
- Personally, I would support not allowing them at all. Not being able to find an enwiki admin? How often does that happen? On the off-chance that does happen and its actually an emergency, stewards can act. I don't see global sysops being necessary, or even very desirable here. Mr.Z-man 17:48, 29 March 2009 (UTC)
I updated information about Global rollbackers adding that they are not allowed to use 'suppressredirect'
here, because 'suppressredirect'
is an admin right. However that Global sysop proposal is in flux now and is not ripe for the discussion yet. So I think there is nothing to discuss at this moment. Ruslik (talk) 16:11, 31 March 2009 (UTC)
Global bot policy
Meta's global bot policy has recently been updated to include double-redirect-fixing. A discussion has begun at Wikipedia talk:Bot policy#Global Policy Page, and until such time as consensus is reached I have changed this page to reflect that existing consensus for global bots only extends to interwiki bots. Please comment there if you have an opinion. Thanks. Anomie⚔ 03:19, 30 March 2009 (UTC)
Category discussion
This page might get a new policy category; the discussion is at WP:VPP#Wikipedia administrative policy. - Dank (push to talk) 01:00, 26 November 2009 (UTC)
Change to steward statement
Given recent widely publicised mistakes by stewards, I suggest that our current policy statement on steward rights is too weak. We should change it. I will shortly post to the village pump, but I suggest the following: Stewards should not use their rights to perform tasks thaat could be performed by local users - not generally, just "don't." This is en-wp - there are always users available to act, and thus that excuse to use steward tools should be removed. Stewards should not use their tools to protect the best intrests of wikipedia - that would involve allowing them to block users who are believed to be disruptive, which is the jurisdiction of local users who have clue - thus, stewards are asked only to use their global rights to protect the critical interests, not the best interests. Hipocrite (talk) 14:35, 23 March 2010 (UTC)
Stewards
Stewards may use their global rollback permission on the English Wikipedia, and may use Special:Undelete to view deleted revisions in the course of their duties as stewards. They are also permitted to the oversight tool to suppress abusive usernames. Stewards generally should not use their global rights to perform tasks that could be performed by local users. In emergency situations where local users are unable or unavailable to act, stewards are asked to use their global rights to protect the best criticial interests of Wikipedia.
In their global role, stewards grant CheckUser and Oversight permissions to all projects (per Arbitration Committee or Board decision), and can remove all permissions (in an emergency, or in response to a user request, Arbitration Committee decision, or Board decision). These actions can affect the English Wikipedia, but are done and logged at meta:Steward requests/Permissions.
- List of users with steward rights
Comment
- I think that "the critical interests" is at least equally ambiguous as "the best interests" is, so therefore the one being used should remain as it's less confusing than a change. Equally ill-defined are "emergency situations" and "unable to act" but that's been an issue for ages. fr33kman 13:12, 26 March 2012 (UTC)