Wikipedia talk:Administrators

Restoration of access following involuntary desysop by WMF Office

• Note, the related VFP discussion (Special:PermaLink/901665843#Allow_bureaucrats_to_quickly_re-sysop_admins_temporarily_de-sysoped_by_WMF_for_carrying_out_out_community_consensus was closed as no-consensus, with a request to further follow up here). — xaosflux ^Talk 13:21, 13 June 2019 (UTC)

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)

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)

@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)

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)

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)

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)

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)

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)

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)

"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)

Good point. But er, what are the usual "for cause" provisions? Hawkeye7 (discuss) 04:52, 12 June 2019 (UTC)

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)

Please point out the section of the policy that allows for the removals that have occurred. –xeno^talk 10:41, 12 June 2019 (UTC)

Wikipedia:Office actions#Secondary office actions Hawkeye7 (discuss) 11:54, 12 June 2019 (UTC)

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. –xeno^talk 16:10, 12 June 2019 (UTC)

Hi followed you from BN: but I don't think you are looking at the whole policy: "administrators and others who have the technical power to revert or edit office actions are strongly cautioned against doing so. Unauthorized modifications to office actions will not only be reverted, but may lead to sanctions by the Foundation, such as revocation of the rights of the individual involved." Alanscottwalker (talk) 16:45, 12 June 2019 (UTC)

Yes, thank you Asw. I still fail to grasp why the precipitate case was not referred to the existing community governance mechanisms, i.e. the Arbitration Committee (which is capable of handling privacy-sensitive matters). –xeno^talk 17:04, 12 June 2019 (UTC)

What's not to grasp? The WMF is given discretion by policy (and as owners, so also by common sense) to decide when the TOU is not being enforced effectively. So, if you want to be the one to exercise that discretion then you have to go to work for them. Now as it happens both the WMF block message (to get back to the purpose of this discussion) and I think me are open to other ways and means to return tools than a new RfA in this case. Alanscottwalker (talk) 17:23, 12 June 2019 (UTC)

One cannot fail to enforce something if not given an opportunity to do so. –xeno^talk 19:44, 12 June 2019 (UTC)

Of course one can and they do. Opportunity is always present to enforce our policies: you may do so, do it poorly, or not do it at all, but the opportunity is ever present. -- Alanscottwalker (talk) 20:11, 12 June 2019 (UTC)

...That entire page was rewritten by a WMF staffer without consensus or any discussion before or after. Weird. --Yair rand (talk) 03:36, 13 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). –xeno^talk 03:38, 12 June 2019 (UTC)

• • 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)
    • 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. –xeno^talk 03:57, 12 June 2019 (UTC)
• 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)
• I support Risker's proposal/idea. TonyBallioni (talk) 04:09, 12 June 2019 (UTC)
  • As do I Dax Bane 22:54, 13 June 2019 (UTC)
• 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)
  • 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)

    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)

  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. –xeno^talk 04:35, 12 June 2019 (UTC)

  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)

  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. –xeno^talk 04:48, 12 June 2019 (UTC)

  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)

• 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)

  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. –xeno^talk 10:47, 12 June 2019 (UTC)

• 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 (u • t • c) 10:14, 12 June 2019 (UTC)
  • @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)
• 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)

• @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)

  @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)

  • (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)
    • @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)

• I would be comfortable with ArbCom deciding, or a decision being made at BN where any controversial cases are referred to a new RfA. I am not comfortable with handing back the tools no questions asked. -- Ajraddatz (talk) 17:29, 12 June 2019 (UTC)
• The WMF had explicitly left it up to us to decide what to do, and therefore I see no reason not to restore the bits immediately upon expiration. If the WMF intended otherwise they would have said. Neither Floq nor Fram has been desysopped by any community process, therefore their original RFAs stand. And to those suggesting ArbCom or an RFA, it seems like neither ArbCom nor the community have any access to the data used to effect the desysop, so it's hard to see what they would be basing a decision on.  — Amakuru (talk) 17:41, 12 June 2019 (UTC)
  • @Amakuru: I'm talking about establishing a policy for this and any future occurrences - in other cases there might be information that arbitrators have the community does not and/or there might be other things that were happening at the time of the desysop that are relevant. We also do not know the users will conduct themselves during the block. I don't see what possible harm comes from waiting another day even when there are absolutely no clouds. Thryduulf (talk) 19:41, 12 June 2019 (UTC)

    @Thryduulf: when I say "immediately" I mean without necessarily mandating a fresh RFA or requiring a full ArbCom confab. A 24 hour waiting period for objections is sensible on any event, certainly. It's not ideal to have to make up policy on the hoof when it directly affects current events, but if it helps clarify things then perhaps an RFC is in order and some new wording on how to handle expired OFFICE desysopps is required. Thanks  — Amakuru (talk) 21:00, 12 June 2019 (UTC)

• I've been thinking very hard about this question, and obviously the only thing that is really clear here is that WMF made an internally contradictory statement. I'm less enthusiastic than others here about ArbCom deciding the issue. ArbCom can certainly evaluate conduct, and so they could consider a case in which they evaluate the conduct of the affected administrators. But ArbCom does not make policy, so I don't think that they can decide what procedure the community can follow. They cannot say either that there must be an RfA or that a Crat should just go ahead and restore the rights. But to get very specific about it, one approach that could work would be for ArbCom to accept a case for the sole purpose of determining whether or not the desysop was "under a cloud". I think that would be reasonable, and then the next step would be determined by existing policy. "Under a cloud" means a new RfA, and "not under" means a Crat can act. (I know that Crats already make decisions about whether or not there was a cloud, but I think we have a difficult situation here where, instead, they should leave that to ArbCom.) And we could ask that the desysopped admin file the ArbCom request, and thereby satisfy the expectation of actively initiating the process.

But otherwise, I think that we have to read the WMF statement about Floquenbeam, dodgy as it is, strictly on face value. They never said that the desysop was indefinite, or that an RfA was mandatory. They only said that it is "temporary" and that there is a 30-day duration. I don't think that we go from there to concluding that they said that the desysop remains in place until there is a successful RfA. "Temporary and lasting 30 days" clearly means that after 30 days the situation returns to what it was before, and that there is an assumption that the admin permissions will be returned at that time unless the community actively decides to do otherwise. --Tryptofish (talk) 23:21, 12 June 2019 (UTC)

Having thought about this more, I'm increasingly coming to the conclusion that the only appropriate course of action following any admin being desysopped for cause, by anybody, is to require a new RFA to demonstrate that they still have the community's trust. If they do then then RFA will easily pass and it's not going to be an issue. If they don't it's far better that we find out before they regain the tools. Thryduulf (talk) 09:28, 13 June 2019 (UTC)

• @Thryduulf: Respectfully, I think that is a completely unfair position. It has been said many times that requiring sitting admins to go through RFA is not a fair process, even for those who've never been under a cloud, for the simple reason that an experienced admin is likely to have pissed off a lot of people in the process of doing their admin duties. Who knows if you or I would pass RFA were we to go through it now? There's a reason why adminship is not subject to reconfirmation. Secondly, if an individual temporarily desysopped under an office action that is typically for reasons that are not disclosed. We have no information on which to judge them. Some people are already slinging mud at Fram without knowledge of why the office banned him. Putting such a user, whom nobody at en-wiki ever thought to desysop before, through an RFA is simply to put them into a kangaroo court, whose outcome cannot be predicted and is not particularly likely to be useful way in judging their suitability for continuing adminship. For me it's very simple. If the WMF tell us we're allowed to resysop someone then we should go ahead and do it. The only other fair alternative to that would be if WMF were to send Arbcom the entire case file an allow them to make a determination. Other than that, no other route is fair to the individual. Thanks  — Amakuru (talk) 13:16, 13 June 2019 (UTC)

Proposal workshop (1)

Should an administrator’s userright be removed by a temporary Wikipedia:Office action, unless specified otherwise the administrator userright may be restored at the user’s request upon the expiration of the temporary action, without prejudice to further examination by local governance mechanisms.

• Workshopping, comments invited. –xeno^talk 13:34, 13 June 2019 (UTC)

  I’ve added “unless specified otherwise” following suggestion by Jo-Jo Eumerus (the underlining is for the workshop, not production). –xeno^talk 17:23, 13 June 2019 (UTC)

• I think "Temporary" is a loaded word here - unless the office plans to personally perform the next step. I see this more as a multi-part activity: (a) The office has removed this access from you (b) The office has implemented a prohibition against you having this access for some period. From the recent comments, it appears that the office won't do the subsequent change, leaving it to a community process - of which we have WP:RFA already. For comparison, if they "temporarily" globally lock you, they will normally be the group to unlock you - they don't leave it up to the stewards to decide. — xaosflux ^Talk 13:46, 13 June 2019 (UTC)

  It’s the language the office has used in these desysoppings. Someone else pointed out that there’s no timer available to automagically reverse userrights changes, so the fact that bureaucrats have to push a button is more of a technicality under this proposal. If their actual motive is to force the user into a fresh RFA, then temporary should be dropped, and RfA specified as required similar to the committee rulings. –xeno^talk 15:52, 13 June 2019 (UTC)

• I'd probably add in "unless specified otherwise by the Wikimedia Foundation"; sometimes they not only pull rights but set out time restrictions and/or other conditions, as happened in this case. Jo-Jo Eumerus (talk, contributions) 14:09, 13 June 2019 (UTC)

  I’ve added “unless specified otherwise”, thank you. –xeno^talk 17:23, 13 June 2019 (UTC)

• Not a comment on the current case, but I'm not super comfortable enshrining any standard which in effect means that the community is condoning misconduct that involves privacy concerns sensitive enough that it can't be shared with the community (also no comment on why the Foundation doesn't feel they can share the information with ArbCom or the functionary team). That's basically what an automatic resysop would amount to, should an applicable situation arise. It's not as if someone could open an ARC requesing "please review this information, the nature of which I am unaware, and which the Foundation refuses to share with you." GMG^talk 15:39, 13 June 2019 (UTC)

  The alternative would be a potential RfA where the community is largely in the dark and forced to sleuth and guess (which rarely goes over well). If there are such concerns, the removal should not be called “temporary”, in my opinion. –xeno^talk 15:59, 13 June 2019 (UTC)

  Yes, the community would need to decide, based on the individual's career, whether they are comfortable restoring access with the understanding that they don't have and will not get all the information. That is less than ideal, but is some level of accountability in a situation where someone may have conduct worthy of deadmining, which ideally would be nearly all situations where the Foundation is compelled to take office action. Yes, it would be a great deal more convenient if the Foundation chose wording that was unambiguious, but I'm not holding my breath for the day when the Foundation is terribly savvy with the projects and communities they oversee. GMG^talk 17:18, 13 June 2019 (UTC)

  I’ve added “unless specified otherwise”. If the WMF or T&S really don’t want us to procedurally resysop on request after a “temporary” sanction based on evidence they won’t disclose, they need to, well, specify. Temporary has a meaning. Also it should be noted that in the case of Fram, the WMFO specifically noted that the removal of administrative userrights was procedural in nature: “The removal of administrator access is intended as enforcement of the temporary partial Foundation ban placed on Fram. It is the community’s decision what to do with Fram’s administrator access upon the expiration of the Office Action ban.” –xeno^talk 17:34, 13 June 2019 (UTC)

• In the absence of any official request to the contrary, yes of course. A case where the WMF *might* be holding back information which they are not even sharing with the people the case is about, we must presume in good faith that that *possible* information just is not important or pertinent to the restoration of rights. --Fæ (talk) 15:46, 13 June 2019 (UTC)
• Mu - I feel that the Office has violated the movement's "appropriate principles and our established constitutional order" referred to by Jimbo,[1] to whom I agree all bans are appealable[2] meaning that T&S shouldn't be modifying any advanced permissions or imposing temporary or local sanctions. They should have only the one tool that they have ever needed for their legitimate purpose of ToU enforcement of serious, legally necessary sanctions: the global permanent ban. Therefore my position is that the new Office actions are an overreach which the community, and admins in particular, should stand firm in asking the Board to reverse, or failing that supporting an all-functionaries fork. EllenCT (talk) 01:09, 14 June 2019 (UTC)
• This sounds pretty good, for a lot of reasons. First, I don't think there will ever be a situation where removal of adminship under OFFICE is ever going to be for such a short duration that it will be impossible for the community in general, or the appropriate community-authorized bodies, to conduct a review. Second, at least at this time we really have no concept of what criteria are being applied to remove these tools. I'll add that I think it's valuable to establish a baseline process now, while we know that this situation has (for the first time ever) occurred; we can always revise it subsequently if other factors change. Risker (talk) 02:21, 16 June 2019 (UTC)
• What are we trying to accomplish here? The bureaucrats can already restore the administrator userright of any user on request - and have done so. If you're trying to prevent them from restoring to users who have them permanently removed, or before the expiration of the temporary action, then this does not accomplish that. Hawkeye7 (discuss) 03:19, 16 June 2019 (UTC)

  @Hawkeye7: part of the admin policy says Former administrators may re-request adminship subsequent to voluntary removal or removal due to inactivity., so my reading is that an office removal fails to meet those criteria to give the requester grounds to seek summary restoration, in that it is certainly not "voluntary". — xaosflux ^Talk 17:29, 16 June 2019 (UTC)

  @Xaosflux: I agree with you completely, but we have recently seen an administrator that had been de-sysopped for successfully apply to have admin userright restored. The bureaucrats considered that section only applies only to voluntary removal or removal due to inactivity, and not admins who have been de-sysopped for cause, who may be re-sysopped on request. Hawkeye7 (discuss) 21:25, 16 June 2019 (UTC)

  @Hawkeye7: I'm sure you are referring to Floq's request which actually was already closed as "not done", but then was overridden by a separate bureaucrat who did it anyway. So "the bureaucrats" are at least divided on the measure, but due to the way we are structured a "not done" requires that no 'crat will agree to do something (c.f. there is an ArbCom case request open on this as well). — xaosflux ^Talk 23:24, 16 June 2019 (UTC)

  I don't know where it says that, but the bureaucrat in question, said in his signing statement that "this project has clear policies and procedures" [3], which he was following (since it would make no sense whatsoever not to follow policies and procedures in a complaint about someone else not doing so). Hawkeye7 (discuss) 04:08, 17 June 2019 (UTC)

• In my opinion, WMF-originated removal of tools should be handled no differently (procedurally speaking) than ArbCom-originated removal of the same tools. Dax Bane 07:24, 18 June 2019 (UTC)

Proposal workshop (1b)

Should any userright be removed by a temporary Wikipedia:Office action, unless specified otherwise the Foundation is indicating that the userright will be restored when the temporary period expires. If the Foundation fails to carry out their obligation in this regard, the userright may be restored by local action at the user’s request, without prejudice to further examination by local governance mechanisms.

If the Foundation did not mean temporary they would not have said temporary. If the Foundation temporarily removes PageMover or somesuch, and the Foundation forgets to restore it, any admin can restore it. And of course bureaucrats can restore admin. If the community sees grounds for removal then we have mechanisms for that. Alsee (talk) 15:18, 16 June 2019 (UTC)

I think we're reading way to far in to the phrasing that was used on this one specific instance, "temporary". My reading is that it is a definite period of prohibition, not any sort of promise of future activity. Your comparison to "page mover" isn't the same, as page mover access is already "discretionary" grantable to pretty much anyone an admin wants to, while we certainly do not allow bureaucrats to discretionarily grant sysop to anyone they want to. And noone is arguing that admins that loose admin access by the foundation can't regain it via an RfA following the ban period. So this is all just back to the initial question of should their be other avenues to restoration, and what should they be? Should they require the former admin to actually request access, or should it be hoisted upon them? Is there a time limit, if so what? Would such restoration be "shall issue" or "may issue", if "may issue" are grounds needed for denial? — xaosflux ^Talk 17:26, 16 June 2019 (UTC)

My reading was that it has the same meaning as ArbCom's own pro forma. I requested an explanation of this back in 2013, and ArbCom responded that (1) the former admin may apply regain access access through RfA after the restriction period, if any, but is not obliged to do so; (2) that ArbCom may itself restore admin access by motion at any time; and (3) it does not preclude restoration of admin rights by other means. Hawkeye7 (discuss) 21:39, 16 June 2019 (UTC)

Is "History" an appropriate section on a policy page?

Page Wikipedia:Administrators is marked by {{policy}}, and is included in Category:Wikipedia policies. Should what seems to be just an informational section "History" (permalink) be moved to information page Wikipedia:Administration? —⁠andrybak (talk) 20:08, 25 June 2019 (UTC)