Requests for Comment/De-bureaucratization and efficiency
This Request for Comments is now closed. Please do not edit this page. New edits may be reverted. |
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
- Archiving as stale and ancient. Please feel free to reopen if there is interest in pursuing, though it hasn't been edited in the past two months. BrandonWM (talk • contributions • global • rights) 19:57, 22 June 2024 (UTC)
Following the success of the request for comment which abolished interwiki administrators it only seems right to me to continue the trend of de-bureaucratization where it is possible and wise to do so. My proposals are once again of a rather radical nature which will seek to upend certain practices and procedures to which many are used to. The principal procedures which are targeted by this request are reopening and undeleting wikis. The premise of the current bureaucratic procedures appears to be an undue assumption that wikis and users cannot be trusted and that consequently Steward supervision is necessary for these actions in order to prevent abuse. I have evidently not been as attentive to these as Stewards have been but from what I have been able to observe fears of abuse are largely unsubstantiated. Similarly to interwiki administrators I believe that the requirement to go through a global group can be abolished while maintaining global supervision in case of abuse. From my perspective the current requests for reopening or undeleting wikis are largely unnecessary and rarely result in action other than approval except in cases where users are mistaking venues due to the confusing nature of these procedures. My proposals seek to flip the status quo on its head by instead assuming that our users and local bureaucrats are of good faith. I do not deny that bad faith and abuse can occur but that is usually the exception and exceedingly rare and rather than having Stewards deal with the norm and be relegated to clerking tasks it will be preferable for them to deal with the exceptions which will in all likelihood be rare and produce limited damage even if they would occur.
I understand that it may be necessary for SRE to make some technical changes in order for these changes to be possible but this was also the case for interwiki administrators and I do not believe that that should be a barrier to these changes.
I would also appreciate feedback from current Stewards and if I am proven wrong and there is in fact a large risk of abuse and circumstances which I am not aware of I will not have any issue to withdraw my proposals. --DeeM28 (talk) 20:09, 26 April 2024 (UTC)
Proposal 1: Reopening wikis[edit | edit source]
If a wiki has been closed for inactivity any user may reopen it.
This will only be effective once SRE sets up a feed to monitor reopenings.
Rationale: There is no clear rationale why wiki reopenings must go through a Steward filter first. It is difficult to see where the harm would occur if a wiki was reopened other than it being closed again which is not really harm. If there is a user who wants to keep a wiki alive that should be encouraged and not stifled by an additional bureaucratic procedure which is not an effective check in any case.
Support[edit | edit source]
Abstain[edit | edit source]
Oppose[edit | edit source]
Comments[edit | edit source]
- As some extra context, there are situations where wikis are procedurally closed and put under managewiki lockdown by Stewards for a number of reasons (primarily policy incompatibility) but left undeleted to allow crats/admins time to create and download backups. Reopens in these cases would not be appropriate and no easy flag exists to differentiate closure types, to my understanding. --NotAracham (talk • contribs • global) 20:11, 26 April 2024 (UTC)
- I'm not technical. But would it be possible in such cases to add a "flag" in the form that only Stewards can control, that locks other users out of reopening? Kind regards, Rodejong 💬 Talk ✉️ Email 📝 Edits Auth → 20:36, 26 April 2024 (UTC)
- ManageWiki locking would serve the same purpose and I assume it would be accounted for when implementing this proposal if it passes. Tali64³ (talk | contributions) 20:38, 26 April 2024 (UTC)
- I'm not technical. But would it be possible in such cases to add a "flag" in the form that only Stewards can control, that locks other users out of reopening? Kind regards, Rodejong 💬 Talk ✉️ Email 📝 Edits Auth → 20:36, 26 April 2024 (UTC)
- I wonder if this is technically viable. Discounting Stewards manually closing wikis, what about if a wiki is manually closed by the administration? --Zeus, aka Blad (t • c • g) 21:55, 26 April 2024 (UTC)
- This RfC has been open for the past month, is there still a desire for this to continue? BrandonWM (talk • contributions • global • rights) 20:47, 28 May 2024 (UTC)
Proposal 2: Undeleting wikis[edit | edit source]
Any user holding local 'managewiki' rights may undelete a wiki. This does not apply if the wiki was deleted for violating global policies.
If a wiki was deleted following community consensus the rules as set out in Wiki governance and voting policy apply.
This will only be effective once SRE sets up a feed to monitor undeletions and a mechanism for wikis to be undeleted directly.
Rationale: If one takes the time to observe the "Undeleting wikis" requests on SR it becomes evident that it is merely a rubber stamping exercise where essentially all undeletion requests are approved and the only requests declined are for procedural reasons. There is in my opinion no reason to prevent bureaucrats from reopening their own wikis and in the unlikely event of abuse this can be dealt with swiftly.
Support[edit | edit source]
Abstain[edit | edit source]
Oppose[edit | edit source]
Comments[edit | edit source]
- Another procedural comment: Differentation on deletion types is not possible today, to my understanding. SRE can correct me on this point, but it'd require net-new development to maintain a record of deletion type, it's also not clear to me how an end-user could best self-serve undeletion of their wiki... while maybe possible, this would probably be a long-term wishlist ask. --NotAracham (talk • contribs • global) 20:15, 26 April 2024 (UTC)
- I made a Phroge task quite a while ago requesting the same thing; it is currently stalled for another task to be finished. As for the feasibility of implementation of this idea, it would theoretically be as simple as checking for the value of the column tracking whether a wiki has been deleted in ManageWiki; for this to work, the column would have to be reconfigured to give it more meaning (i.e. "0" for not deleted, "1" for deletion via inactivity, "2" for deletion by bureuacrat, and "3" for deletion by Steward/other functionary). That would solve the issue of bureaucrats undeleting wikis closed for policy violations while not taking up too much extra space. Tali64³ (talk | contributions) 20:23, 26 April 2024 (UTC)
- As an alternative, we can see about making the managewiki lock apply to undeletion as well. Self-serve undeletion would definitely be the trickier part, in my opinion. Possibly something could be done through the custom wiki not found page, though it may be a bit complicated. -- Void Whispers 20:52, 26 April 2024 (UTC)
- I had a similar idea to this in T11634 as Tali pointed out, though mine was a bit more restrictive and proposed to have multiple bureaucrats in order to undelete but after reading this RfC and due to that solution being very difficult to achieve I'm more inclined to support a more permissive approach like here. I think either way it's about time to differentiate closures and deletions even just for the sake of sitenotices/the deleted wiki error page which can be confusing if a wiki has in fact been closed or deleted for other reasons than inactivity. For self-serve deletion, I wonder if the solution could just be to whitelist Special:ManageWiki since either way "marked as deletion" is only a status and the wiki is actually still fully intact. Reception123 (talk) (C) 09:57, 27 April 2024 (UTC)
- As an alternative, we can see about making the managewiki lock apply to undeletion as well. Self-serve undeletion would definitely be the trickier part, in my opinion. Possibly something could be done through the custom wiki not found page, though it may be a bit complicated. -- Void Whispers 20:52, 26 April 2024 (UTC)
- I made a Phroge task quite a while ago requesting the same thing; it is currently stalled for another task to be finished. As for the feasibility of implementation of this idea, it would theoretically be as simple as checking for the value of the column tracking whether a wiki has been deleted in ManageWiki; for this to work, the column would have to be reconfigured to give it more meaning (i.e. "0" for not deleted, "1" for deletion via inactivity, "2" for deletion by bureuacrat, and "3" for deletion by Steward/other functionary). That would solve the issue of bureaucrats undeleting wikis closed for policy violations while not taking up too much extra space. Tali64³ (talk | contributions) 20:23, 26 April 2024 (UTC)
- I am likely to Oppose this request per the above concerns. --Zeus, aka Blad (t • c • g) 23:21, 26 April 2024 (UTC)
Proposal 3: Restricted extensions[edit | edit source]
The community requests that SRE prioritizes the development of mechanisms that will minimize the need to request extensions to be enabled.
Support[edit | edit source]
Abstain[edit | edit source]
Oppose[edit | edit source]
Comments[edit | edit source]
- Not sure what is being proposed here, more clarity needed. --NotAracham (talk • contribs • global) 20:17, 26 April 2024 (UTC)
- It usually goes for SMW and Cargo, and was mainly dictated by the fact that back in 2023 (or 2022?) Cargo brought majority security risks leading to temporary disable across all wikis, both which relied on it very heavily, and those which just had it enabled and not actually used. Then it took down the entire farm at least once. In short - a very resource heavy extension which must be used with responsibility, and SMW falls into same category. Legroom (talk) 21:22, 26 April 2024 (UTC)
- What I'd say to this is that if there was an easy way for SRE to do this we would. I know that in the past we did tend to be overly restrictive (i.e. have file types as restrictive) but in this case Cargo poses a lot of issues so it's best to make sure users know what they're getting into. In terms of SMW, a solution could probably be figured out but I wouldn't really qualify it as a priority as we don't get that many requests and SRE are able to handle when they come in. Reception123 (talk) (C) 09:59, 27 April 2024 (UTC)
- The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.