Jump to content

Wikipedia talk:Administrators: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
Line 42: Line 42:
:::::Please point out the section of the policy that allows for the removals that have occurred. –[[User:xeno|<b style="font-family:verdana;color:#000">xeno</b>]][[user talk:xeno|<sup style="color:#000">talk</sup>]] 10:41, 12 June 2019 (UTC)
:::::Please point out the section of the policy that allows for the removals that have occurred. –[[User:xeno|<b style="font-family:verdana;color:#000">xeno</b>]][[user talk:xeno|<sup style="color:#000">talk</sup>]] 10:41, 12 June 2019 (UTC)
::::::[[Wikipedia:Office actions#Secondary office actions]] [[User:Hawkeye7|<span style="color:#800082">Hawkeye7</span>]] [[User_talk:Hawkeye7|<span style="font-size:80%">(discuss)</span>]] 11:54, 12 June 2019 (UTC)
::::::[[Wikipedia:Office actions#Secondary office actions]] [[User:Hawkeye7|<span style="color:#800082">Hawkeye7</span>]] [[User_talk:Hawkeye7|<span style="font-size:80%">(discuss)</span>]] 11:54, 12 June 2019 (UTC)
:::::::I was taking about the community’s policy at [[Wikipedia:Administrators]], but okay- {{u|Hawkeye7}}: please explain how Floquenbeam’s action involves a {{tq|“major [breach] of trust performed by Wikimedia functionaries or other users with access to advanced tools that [is] not possible to be shared with the Wikimedia communities due to privacy reasons and therefore can not be handled through existing community governance mechanisms.”}} ''Everything'' Floquenbeam did was out in the open, in fact it was telegraphed in advance. There is nothing private in this case. It appears that Trust and Safety has violated the section you’ve linked as the committee could have heard a case regarding the unblock, at the least, if not the precipitating case re: Fram. –[[User:xeno|<b style="font-family:verdana;color:#000">xeno</b>]][[user talk:xeno|<sup style="color:#000">talk</sup>]] 16:10, 12 June 2019 (UTC)

*Administrators serve at the pleasure of the community, not the WMF. The section on removal of administrators overleaf does not contain a provision for summary revocation by [[User:WMFOffice]]. Once the office actions (which we apparently have to just accept without any avenue of appeal) have lapsed, summary restoration should occur to restore governance to the local community (at which point, local processes may be engaged if needed). –[[User:xeno|<b style="font-family:verdana;color:#000">xeno</b>]][[user talk:xeno|<sup style="color:#000">talk</sup>]] 03:38, 12 June 2019 (UTC)
*Administrators serve at the pleasure of the community, not the WMF. The section on removal of administrators overleaf does not contain a provision for summary revocation by [[User:WMFOffice]]. Once the office actions (which we apparently have to just accept without any avenue of appeal) have lapsed, summary restoration should occur to restore governance to the local community (at which point, local processes may be engaged if needed). –[[User:xeno|<b style="font-family:verdana;color:#000">xeno</b>]][[user talk:xeno|<sup style="color:#000">talk</sup>]] 03:38, 12 June 2019 (UTC)



Revision as of 16:10, 12 June 2019

WikiProject iconWikipedia Help NA‑class Top‑importance
WikiProject iconThis page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.
NAThis page does not require a rating on the project's quality scale.
TopThis page has been rated as Top-importance on the project's importance scale.

Restoration of access following involuntary desysop by WMF Office

Hello, the recent Fram situation, and likely the follow up related to Floquenbeam has brought to question part of the administrator policy. That is, should an admin be involuntarily desysoped by the WMF Office - what avenues to access restoration should be available following an prohibition period. If you would like to address a "Should we just ignore and override WMF Office" - please do so in a new discussion area. I see going through a new RfA as an available option already - but should there be other options? In any event, I think it is obvious that if an intervening community action/arbitration committee action adds additional prohibitions that they would continue under the existing scheme. Thank you for your feedback, — xaosflux Talk 01:19, 12 June 2019 (UTC)[reply]

If anyone wants to override WMF, I think they will, discussion or no. I see the situation as similar to having rights emergency removed by a steward - but we don't really address that either. --Rschen7754 01:26, 12 June 2019 (UTC)[reply]
@Rschen7754: I see the ignore wmf route as different topic (which certainly can be discussed) - but to keep this part on track, I'd like to clarify if there is support for non-RfA restorations following a ban. — xaosflux Talk 01:31, 12 June 2019 (UTC)[reply]
If you're asking me personally, I would say no. There is the credible argument that the rights were removed under a cloud. --Rschen7754 01:35, 12 June 2019 (UTC)[reply]
Adminship on this project is a measure of the community (and the Arbitration Committee)'s trust in an editor, not a measure of the Wikimedia Foundation's trust in that editor. Thus, unless there's some indication that the office-desysopped admin has lost the community's trust (which is clearly not the case for both of the admins the WMF desysopped recently), then there is no cloud and their admin rights should be restorable on request. * Pppery * it has begun... 01:41, 12 June 2019 (UTC)[reply]
Well, that's the thing. You and I may still trust them, but enough people probably do not that a new RFA would be a better alternative (as evidenced by some comments that are starting to come from different editors). --Rschen7754 01:47, 12 June 2019 (UTC)[reply]
I would have to say no, based on the reasoning above. The only way of establishing the community's trust in an editor is through ArbCom or RfA. Surely an office action counts as removal under a cloud. Hawkeye7 (discuss) 01:45, 12 June 2019 (UTC)[reply]
There is an open question as to whether or not this is genuinely under a cloud, however, given Floq was essentially being put into a situation I wouldn't wish on my worst enemy, and she chose to side with the community (who agrees, absent any new information, that this is an overreach). —A little blue Bori v^_^v Bori! 02:41, 12 June 2019 (UTC)[reply]
Floquenbeam was under no obligation to act, and did so with no illusion that a desysop would likely be forthcoming. Probably also anticipated the possibility long block for violating ToS by overturning an office action and/or disrupting Wikipedia to make a WP:POINT. Hawkeye7 (discuss) 04:52, 12 June 2019 (UTC)[reply]
"Under a cloud" is generally used to annotate resignations in the face of scrutiny, whereas both Floq and Fram were de-tooled for cause. As such, the usual "for cause" provisions regarding regaining the tools should apply here (unless the WMF have specifically stated otherwise) Dax Bane 03:00, 12 June 2019 (UTC)[reply]
Good point. But er, what are the usual "for cause" provisions? Hawkeye7 (discuss) 04:52, 12 June 2019 (UTC)[reply]
Applying for the tools through the RFA process, sometimes with a minimum waiting time appears to be the usual procedure for re-mopping for cause permission revocations Dax Bane 05:57, 12 June 2019 (UTC)[reply]
Please point out the section of the policy that allows for the removals that have occurred. –xenotalk 10:41, 12 June 2019 (UTC)[reply]
Wikipedia:Office actions#Secondary office actions Hawkeye7 (discuss) 11:54, 12 June 2019 (UTC)[reply]
I was taking about the community’s policy at Wikipedia:Administrators, but okay- Hawkeye7: please explain how Floquenbeam’s action involves a “major [breach] of trust performed by Wikimedia functionaries or other users with access to advanced tools that [is] not possible to be shared with the Wikimedia communities due to privacy reasons and therefore can not be handled through existing community governance mechanisms.” Everything Floquenbeam did was out in the open, in fact it was telegraphed in advance. There is nothing private in this case. It appears that Trust and Safety has violated the section you’ve linked as the committee could have heard a case regarding the unblock, at the least, if not the precipitating case re: Fram. –xenotalk 16:10, 12 June 2019 (UTC)[reply]
  • Administrators serve at the pleasure of the community, not the WMF. The section on removal of administrators overleaf does not contain a provision for summary revocation by User:WMFOffice. Once the office actions (which we apparently have to just accept without any avenue of appeal) have lapsed, summary restoration should occur to restore governance to the local community (at which point, local processes may be engaged if needed). –xenotalk 03:38, 12 June 2019 (UTC)[reply]
    • So if Fram or Floquenbeam show up on BN the day after their respective office-mandated desysopping expires asking for the tools back, where would you land in the "sure"/"go to RfA first"/"recuse" triangle, xeno? Dax Bane 03:43, 12 June 2019 (UTC)[reply]
      • It has been pointed out to me that there does not presently exist in the policy an avenue for bureaucrats to summarily restore privileges “temporarily” removed by office action. This is of course a function of the unprecedented (on this project) nature of these removals. Should community consensus be established that bureaucrats may restore temporarily removed privileges summarily (and isn’t that a defining characteristic of “temporary”?), I would continue to carry out the community’s will to the best of my abilities. –xenotalk 03:57, 12 June 2019 (UTC)[reply]
  • This is certainly a weird one. We know what kind of "situation" has led to Floq's desysop, but we really don't know what triggered the Fram desysop. Indeed, we don't know if he was desysopped to prevent him from using the remnants of admin permissions that aren't affected by his block, or for some other reason. We do, however, have a community process related to removal of admin permissions; I know it's not popular to say it, but Arbcom is that route. I'd suggest that Arbcom should treat these desysops as the equivalent of a case request from the community (because realistically both cases have raised questions within the community), decide whether or not a "case" or "review" is warranted, and determine whether or not re-RFA is required, or if either of these admins can regain permissions on request. While it's not a perfect solution - nothing we do here will be - I'd suggest something along the lines of "Should an administrator's permissions be removed because of a non-permanent WMF OFFICE action, the Arbitration Committee will determine whether or not to review the administrator's permission level and decide whether a new RFA is required at the completion of the WMF OFFICE action. Should the Arbitration Committee decline to review the administrator's permission, or supports by motion that the administrator may regain administrator permission on their request to the Bureaucrat Noticeboard, no new RFA will be required." Risker (talk) 04:01, 12 June 2019 (UTC)[reply]
  • I support Risker's proposal/idea. TonyBallioni (talk) 04:09, 12 June 2019 (UTC)[reply]
  • Automatically resysopping editors banned by WMF office action would set a horrible precedent. As the WMF has already said they might not share details of actions with ArbCom, a case may not be able to treat the subject fairly. A new RfA is the only way to properly gauge the will of the community in each of these cases and in any going forward. – bradv🍁 04:22, 12 June 2019 (UTC)[reply]
    • I'm not sure that I follow you. Why would it set a horrible precedent? Do you have a problem with the Arbitration Committee reviewing their admin permissions? They are, after all, the elected representatives of the community specifically tasked to review admin permissions. Risker (talk) 04:28, 12 June 2019 (UTC)[reply]
      I can imagine a case where somebody did something truly awful and deserved to be desysopped, but for whatever reason WMF enacted it rather than Arbcom. In such a case, Arbcom may not be privy to the evidence and may not be able to put together a fair case. To your second question, I'm of the opinion that Arbcom should continue to be the only body that can desysop people for cause, but if the WMF is going to enact this change there isn't much we can do other than handle this on a case-by-case basis. – bradv🍁 04:33, 12 June 2019 (UTC)[reply]
    Bradv Floquenbeam was not banned, they were “temporarily” desysopped. In cases like Fram (with private evidence and in camera decisions), how can the community be reasonably expected to deliberate on an administrator’s fitness when the incident they gave rise to the removal of access is not disclosed? The status quo should be restored and the arbitration committee may be engaged if community members feel it necessary. –xenotalk 04:35, 12 June 2019 (UTC)[reply]
    Xeno, the ideal situation right now would be for the WMF to reverse their ban and refer the matter to ArbCom. If that doesn't happen, I don't know how we're going to handle it in a year. Meanwhile, I'm just concerned about setting a precedent that we may not be able to undo (i.e. someone gets justifiably desysopped, and ArbCom doesn't have the evidence to re-desysop them). – bradv🍁 04:39, 12 June 2019 (UTC)[reply]
    The real question is: Why is the Arbitration Committee being bypassed? The T&S page says that they will step in when local procedures have failed. From what we’ve been told, local procedures were never even given an opportunity to handle the situation, despite the committee members being signatories to the confidentiality agreement for access to non-public information. I believe the justification is that T&S cannot disclose a complainant’s identity to the committee but there is no reason they cannot instruct the complainant to first exhaust local processes (which can be done in private) and confirm that they have done so before taking drastic actions that harm community/WMF relations. –xenotalk 04:48, 12 June 2019 (UTC)[reply]
    Xeno, I agree entirely, and it's a question I really hope the WMF answers. It seems to me the relationship between ArbCom and the WMF has been damaged by this incident and in need of repair, which is also why I'm suggesting we not put ArbCom in between the WMF and the community when this thing expires. – bradv🍁 04:51, 12 June 2019 (UTC)[reply]
  • To voice an opinion on Xaosflux's original question, I think that any of the desysops as Office actions would have to go through RfA. The "under a cloud" phrasing is irrelevant, as it was not a voluntary de-sysop or one due to inactivity. The only other de-sysoppings for cause are the ones that ArbCom imposes as part of their normal process, and they usually specify under what circumstances the tools would be returned: either a new RfA, sometimes after a mandatory waiting period, or appeal to ArbCom. I suspect that WMFOffice's phrasing "a RfA can be opened once 30 days elapse, and the community may decide on the request at that time in such or another way" was meant to leave it open to enwiki's policy - they're neither reinstating Floquenbeam after 30 days, nor barring them from being reinstated after that time. If they intended the tools to be automatically returned, they would have said that. Instead, the tools were removed involuntarily (and "for cause", regardless of whether anyone here agrees with that cause). A 'crat restoring the tools prior to 30 days would be reversing an office action, and a 'crat restoring the tools after that but without consensus (and I see no reason to establish that anywhere but at WP:RFA) would be in violation of WP:CRAT "they are bound by policy and consensus only to grant administrator or bureaucrat access when doing so reflects the wishes of the community".
  • The same would be true for Fram, with the possible but unlikely exception that the WMF might intend to automatically restore their sysop bit at the end (if the theory is that the desysop was to prevent certain admin tools from being exercised while the account was blocked). Ideally the office would clarify their intent (among many other things...) before it becomes relevant, however, I think the most likely answer is that they too would have to go through an RfA unless the office spontaneously reverses their decision. ST47 (talk) 08:42, 12 June 2019 (UTC)[reply]
    The community can express their wish that these “temporary” desysops be treated as such, and reversed at their expiry. Unless WMFOffice is using some alternate definition of temporary, policy considerations can be established that new RfA is not required followed these unprecedented “temporary” removals that have no backing in the policy. –xenotalk 10:47, 12 June 2019 (UTC)[reply]
  • I don't know where things will end up in 30 days, but after the dust is settled, barring some radical changes the English Wikipedia will still be part of the WMF when any of this becomes relevant. The Floq desysop note suggests the WMF feels a new RfA is required for that bit to be restored. Whether any of us cares is another matter, but it would suggest that any other process would be open "rebellion" against the WMF after "hostilities" had ended. I like Risker's suggestion, but a new RfA would and always will be cleaner. It'll be an easy seven days of Floq adoration, and will establish a strong, irrefutable message going forward. It may even be quicker than ArbCom. If the WMF doesn't demand a new RfA, I'd be happy to expand the bureaucrat discretion to such cases of "temporary" removal. In short, I think our general policy should be to 1) clarify whether the WMF will require an RfA, 2) if not, refer to bureaucrats, but 3) in all cases, heavily prefer a new RfA. ~ Amory (utc) 10:14, 12 June 2019 (UTC)[reply]
    • @Amory: The WMF wrote "a RfA can be opened once 30 days elapse, and the community may decide on the request at that time in such or another way". I think that means that they wouldn't objec to the policy xeno suggests. I also support that policy. KSFT (t|c) 10:53, 12 June 2019 (UTC)[reply]
  • Speaking generally, I think that if the WMF desysops someone temporarily and clearly indicates a single method by which tools may/will be regained then that method should be used. In other circumstances, I think the user concerned should never be resysopped without asking for the tools back. They may do this by initiating or accepting an RFA (self-) nomination, or by asking the crats. The crats would then have the option of restoring after 24 hours (given that it's not impossible that a WMF-desysopping was coincident with other things that would place the editor under cloud) or requesting the editor pass an RFA first. In all cases an RFA should be run and closed as normal. If the crats do not want this, then the request should be made to the Arbitration Committee instead per Risker. Thryduulf (talk) 11:51, 12 June 2019 (UTC)[reply]
  • @Thryduulf:, sorry to repeat myself, but although I know the WMF has the power to desysop permanently or temporarily, where does the ability to make a desysop only temporary and then specificy a method for regaining the tools? Are we even sure this isn't a misunderstanding of enwiki procedures? Doug Weller talk 15:21, 12 June 2019 (UTC)[reply]
    @Doug Weller: lets pretend we can ignore the WMF "method" statement and say it was just "use your community process" as they are not asserting that they will take care of restoration processes anyway. I'm trying to determine if there is support for a community process in addition to RfA for giving administrator access to people that were involuntarily desysoped by the foundation. — xaosflux Talk 15:31, 12 June 2019 (UTC)[reply]
    • (edit conflict) Well they say that CU and OS can only be granted to people who have been through an RFA or a similar process. So it is not implausible they could specify that tools should only be returned after they pass an RFA or similar (currently that means an RFA or being elected to arbcom, afaik nobody has officially asked about anything else). They could also say that arbcom must be consulted first (presumably this would only happen if they had provided private information to arbcom regarding the matter), or they could say that the tools can be restored on request - all of these seem perfectly reasonable parts of a temporary desysop motion (for want of a better word) to me. Wehther they ever would do any of these I don't know (all we know is they haven't on this occasion), but if they do I don't see why we would or should do something different. Thryduulf (talk) 15:38, 12 June 2019 (UTC)[reply]
      • @Xaosflux: As I see it, assuming the WMF don't specify anything different, once the desysop period expires the the plausible options in practice are: (1) any crat can restore the tools at any time; (2) any crat can restore immediately on request from the editor; (3) 24 hours after the request, any crat can either restore the tools or decline to do so without a new RFA (based on comments received during that 24 period); (4) require a new RFA in all cases; (5) require arbcom to explicitly decide whether (i) an arbcom case is required, (ii) the crats can restore immediately, (iii) the crats can restore after some waiting period, or (iv) a new RFA is required. Personally I would only support options 3, 4 or 5 and would strongly oppose (1). Thryduulf (talk) 15:46, 12 June 2019 (UTC)[reply]