Requests for Comment/Changes to the Dormancy Policy (3)

The changes proposed here relate to wikis being made read-only (as in locked from editing) being part of the dormancy process.

The proposals below are not dependent on other proposals unless otherwise stated. K599 (talk) 16:53, 15 December 2021 (UTC)

General commentary
This section is for commentary, not for voting.


 * If anything is unclear, it would make sense to ask nicely for clarification, not immediately making an oppose vote based on misunderstood information. And I will provide clarification, as I tried to in the central notices RfC and this discussion about central notices, like campaign types for your preferences. K599 (talk) 16:54, 15 December 2021 (UTC)

I don't think it is ideal to create an additional RfC to expand upon the details of an already messing/ongoing RfC, given this now splits between two pages, uses a formal structure that's difficult to change through discussion once votes are cast, and could well indeed be influenced by the passage or failure of details on existing RfCs. In other words I find this page to be premature, and better represented through the CN or informal discussion to iron out generally agreeable stances to then vote upon once there is a preliminary assessment through the original RfC. --Raidarr (talk) 18:11, 15 December 2021 (UTC)
 * Please state what "details" of the other RfC that this RfC is apparently "expanding" upon. K599 (talk) 19:55, 15 December 2021 (UTC)
 * Perhaps calling it 'details' is clerically incorrect, but I hold that the overall topical relevance and discussion is a splinter of the existing RfC and does not stand well here on its own. Good luck with it in any case. Per discord and other on-wiki discussion you seem quite convinced of the path. --Raidarr (talk) 03:00, 16 December 2021 (UTC)
 * Even though they both cover the topic of the Dormancy Policy, the intention for this is that it deals with different aspects of it, and therefore discusses different issues. That said, looking over the other RfC, I suppose I'll acknowledge that it could be considered that there might be overlap concerning adoption. K599 (talk) 22:14, 16 December 2021 (UTC)
 * I hadn't noticed that! YellowFrogger (✉ Talk  ✐ Edits ) 19:58, 15 December 2021 (UTC)

Would you be opposed to changing references to "bureaucrats" to "users with the managewiki right"? Some wikis might replace the bureaucrat group or use it for something different, so wording it this way will refer to the equivalent of bureaucrats in such situations. — Arcversin (talk) 16:29, 26 December 2021 (UTC)
 * 1)  Per my message here, I disagree with the hasty opening of a new RfC for this very controversial topic and would prefer that this request is withdrawn and a new Dormancy Policy RfC is created after a draft is first opened and discussed/collaborated on to create several proposals that can be voted on. Reception123 (talk) ( C ) 20:17, 15 December 2021 (UTC)
 * I'll put this page in a "drafts" section, but I'm not going to throw away the proposals. K599 (talk) 22:03, 15 December 2021 (UTC)
 * Arcversin This is a minor semantic difference. Dormancy Policy may mention the  role, but where a wiki had no   role, Stewards would treat any group(s) holding the   user right as functionally equivalent. Dmehus (talk) 17:27, 26 December 2021 (UTC)
 * I know, just wanted to do so for clarity (and since it seemed to involve some automated stuff). — Arcversin (talk) 01:10, 27 December 2021 (UTC)

Part 1 (Inactivity state)

 * The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
 * This proposal is unclear what's being proposed, noting users have already started !voting in a draft RfC before !voting had yet to begin. Procedurally, draft RfCs should be formulated as a subpage of one's own user userspace. Since that's happened, I'm going to close this because it is unclear what is being proposed. If the proponent proposes that the read only state be removed from closed wikis, that is not technically feasible within the current wiki deletion script framework. It relies on the date of the most recent recent change for determining the date which the wiki was last edited. As inactive wikis are often a target of vandalism only accounts and spambots, this would effectively give spambots, or even LTAs, a de facto veto over Dormancy Policy (case in point being, now since manually deleted). Any  , or really any user holding the   user right, may reopen a wiki. Where there are no recently active bureaucrats, a Steward can be requested to assist in fulfilling this request. As to the point about notifying bureaucrats of a wiki's closure and/or deletion via e-mail and/or user talk page on Meta Wiki, this is either (a) already done and/or (b) in the process of being done. Dmehus (talk) 17:22, 26 December 2021 (UTC)

Don't set wikis to read-only as part of the dormancy process. The particular changes this entails are the following.

Change the current process of going inactive, then closure, then deletion eligibility, into going inactive, then deletion eligibility. The time period for being closed would become part of the time period for being inactive.

Manual closure of wikis is not affected.

As closure would stop being part of the dormancy process, emails and any other relevant notifications will be sent to bureaucrats when their wikis become inactive.

Changes to adoption are detailed in part 2.

The table below shows the new timeline for the dormancy process. You can see the current one on Dormancy Policy.

As part of transition, all automatically closed wikis are set to be inactive, and bureaucrats of inactive wikis are sent an email alerting of inactivity.

Support (1)

 * 1) I don't believe it makes sense to lock editing for inactivity. Locking editing is putting up an unnecessary barrier to reviving an inactive wiki for hopeful communities out there. The adoption process involves telling the requestor to make a request for local rights if they want them, and it would help if they didn't have to deal with a bureaucratic process just to even start editing the wiki. Really, if someone wants to edit a wiki that's "inactive", then the wiki would have an active user, and that active user should be able to make that wiki active. K599 (talk) 16:54, 15 December 2021 (UTC)
 * 2) It's always been an inconvenience and backwards that the solution to no edits is to prevent edits, therefore guaranteeing that there will be no edits. Instead, we should encourage people to edit, and if it doesn't happen despite that then that's a problem. Locking off editing not only requires a crat to unlock it it's the backwards message. Naleksuh (talk) 02:10, 17 December 2021 (UTC)
 * I will refrain from making comments on the substance of your argument and just wanted to say that it looks like this request was added under "Draft requests" which would indicate that it is not to be voted on. --DeeM28 (talk) 09:10, 17 December 2021 (UTC)
 * 1)  I don't think wikis should be made read-only before being deleted. Tali64³ (talk) 23:18, 23 December 2021 (UTC)

Oppose (1)

 * 1)  I'm not convinced by the arguments advanced and think that the current system is perfectly fine. Why change what works? Reception123 (talk) ( C ) 20:10, 15 December 2021 (UTC)
 * Do you have any reasoning to justify wikis being made read-only being part of the dormancy process? As far as I can tell, this aspect only seems to serve as being a blocker to anyone trying to make an inactive wiki into an active one again. K599 (talk) 20:14, 15 December 2021 (UTC)

Part 3 (Deletion notification)
Bureaucrats will be notified through email, and any other methods that are used in other parts of the dormancy process, when their wikis become eligible for deletion as defined in Dormancy Policy.

Support (3)

 * 1) An extra notification to make sure that leaders of communities are aware of what happened to their wikis wouldn't hurt, in case they become active after deletion eligibility. K599 (talk) 16:54, 15 December 2021 (UTC)
 * 2)  It's only fair to notify the bureaucrats of a wiki when the wiki is eligible for deletion. That way, they're given time to stop the deletion. Tali64³ (talk) 23:18, 23 December 2021 (UTC)

Comments (3)

 * 1) But that already exists; what do you want to change here? YellowFrogger (✉ Talk  ✐ Edits )</b> 19:59, 15 December 2021 (UTC)
 * I don't see anything on Dormancy Policy that says that anyone is notified for wiki deletions. If I made a mistake, then I apologize, but I'd also like clear confirmation as well. K599 (talk) 20:09, 15 December 2021 (UTC)
 * I have a personal notes wiki. When he went into inactivity; I received an email notification. Have you never tried this? --YellowFrogger (Talk — ✐) 20:27, 24 December 2021 (UTC)
 * This proposal is specifically for deletion eligibility, which is different from inactivity/closure, as it's stated on Dormancy Policy. I'm aware that at least emails are sent for closures. K599 (talk) 21:04, 24 December 2021 (UTC)
 * 1)  What's your plan for the 3rd RfC on the same subject? --DarkMatterMan4500 (talk) (contribs) 20:12, 15 December 2021 (UTC)
 * Please read what the proposals say they are trying to do. K599 (talk) 22:08, 15 December 2021 (UTC)


 * The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section

Part 2 (Adoption) (archived, don't vote)
With part 1 getting rid of automatic closures, adoption should be changed from reopening to requesting local rights for a wiki when there is a request made on a wiki and its existing users designated to handle them according to local policies are inactive. This does not change anything for how manually closed wikis are handled.

Support (2)

 * 1) These changes compliment the changes in part 1. Of course, if anyone has ideas for alternatives, feel free to say them. K599 (talk) 16:54, 15 December 2021 (UTC)
 * 2) if Proposal 1 passes through (which it looks like it might). Tali64³ (talk) 23:18, 23 December 2021 (UTC)

Comments (2)

 * In hindsight, this part isn't necessary, and the current adoption system should presumably still work. K599 (talk) 04:03, 22 December 2021 (UTC)