Requests for Comment/User close policy amendments


 * The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
 * The RfC is closed as follows:


 * Proposal 1: Successful.
 * Proposal 2: Unsuccessful.
 * Proposal 3: Successful. Reception123 (talk) ( C ) 12:21, 12 April 2023 (UTC)

At the end of 2019 along with other users I proposed the User close policy. The reason for the necessity of this policy was the need to prevent new Miraheze users from attempting to "collecting hats" and wasting the time of the community by having users spend their time opposing and debating requests and waiting until the policy periods for closure were met. Since then from what I have managed to observe the policy has worked relatively well to achieve its goals. Nevertheless there have been some minor issues and some improvements that I wish to address in this small RfC. I am sure that some will think that there are more important priorities than this minor policy but I still believe it is worth applying these minor fixes to it if the community agrees with my justifications.

The first issue is that the policy was written in such a way where it was initially had in mind that it would apply to users with non-advanced permissions only and that the advanced groups would use their inherent discretion to close requests. I have observed that users with advanced permissions have instead been relying on this policy which gives them a more solid justification to close requests. In this sense it would be useful for us to clarify this in the policy.

The second issue is that the policy is too strict in its 3 votes requirement in cases where a user with less than 30 edits makes a request which beyond any doubt has no chance of passing. It sometimes is the case that users request permissions even as their first or second edit on Meta in which case it is evident that we do not need to wait for 3 votes to determine that the request has no chance of passing. The 3 votes requirement is useful in more complex requests where a user does have more edits than 30 but it is still clear that the permission they are requesting is not appropriate for them.

The third issue is that the policy only speaks of Stewards overturning user closes where in fact local groups such as bureaucrats may be the ones who have initial jurisdiction over some requests. The reason why only such groups may overturn closes is to avoid the situation where an edit war would occur over whether a close was justified or not between users. --DeeM28 (talk) 15:53, 4 April 2023 (UTC)

Proposal 1
It is clarified that while Stewards and Meta bureaucrats retain their inherent discretion to close requests they may rely on this policy as well.

Support

 * 1)  as proposer. DeeM28 (talk) 15:53, 4 April 2023 (UTC)
 * 2)  Isn't this the status quo? BrandonWM (talk • contributions • global • rights) 00:19, 5 April 2023 (UTC)
 * 3)  While this is already an implied best practice, better to codify that advanced roles are similarly-empowered to close under same rationale.  If an autoconfirmed user can do so, there's no reason I'm currently aware of that a Steward/Meta Crat shouldn't also be able to do so. --NotAracham (talk • contribs • global) 00:40, 6 April 2023 (UTC)
 * 4)  I believe this is a good idea for the same reason as others. Collei (talk) 05:44, 7 April 2023 (UTC)

Proposal 2
In addition to the current policy: Autoconfirmed and confirmed users are allowed to close any request for permissions as unsuccessful (global rights and local rights) if the user in question has less than 30 edits on Meta, they have not provided a valid justification for the request and there aren't any valid (non-sockpuppet/meatpuppet) support votes.

Support

 * 1)  as proposer. DeeM28 (talk) 15:53, 4 April 2023 (UTC)
 * 2)  As an alternative to the existing policy. BrandonWM (talk • contributions • global • rights) 00:20, 5 April 2023 (UTC)

Oppose

 * 1) Per comments, adding an  that could be readily converted to a  there is a minimum length of time before this clause can be used to close, to account for trusted but non-meta community members. --NotAracham (talk • contribs • global) 00:50, 6 April 2023 (UTC)
 * 2) This is number more number creeep, and doesn't help much. I think it's good for there to be at least some !votes so that a closure would roughly affect consensus rather than closing without anything (which even the affected user might take a problem with). Also another problem with the number creep is it could be used to close successful requests. I successfully requested a permission on Meta with only just 12 more edits than the proposed limit, so in theory this might stop possibly successful requests. Also seems like a solution looking for a problem; what is the issue with simply waiting until there are 3 comments? There's no hurry nor is a request doing any harm sitting there. Also, there is no way to define a "valid justification" for the purposes of policy Naleksuh (talk) 05:15, 6 April 2023 (UTC)

Comments

 * Should this clause be read as an alternative to or an addition to the current rule of three dissenting 'too soon' votes? --NotAracham (talk • contribs • global) 16:41, 4 April 2023 (UTC)
 * It is more of an alternative I would say. If a user has less than 30 edits the request may be quickly closed without the necessity of three users. If a user has more than 30 edits only the 3 user oppose method may be used. --DeeM28 (talk) 19:47, 4 April 2023 (UTC)
 * Thanks for the clarification, I like where this is going as an alternative but don't think I support this in its current form. There are valid community-involved users that don't happen to engage on Meta (e.g. primarily a discord presence) that are nevertheless very active in their local communities and helpful informal volunteers via other channels, several of our unofficial CSS/JS helpers come to mind.  Perhaps a good middle ground on this is a time-bounded clause, e.g. request must have stayed up for 24 hrs for closure under this alternative standard? --NotAracham (talk • contribs • global) 00:47, 6 April 2023 (UTC)
 * I would agree with your 24 hours proposed limit idea. --DeeM28 (talk) 10:04, 6 April 2023 (UTC)
 * If it's been up for 24 hours and 3 people haven't said it's a notnow request, then maybe it isn't one. Besides, the point of non-steward closures is supposed to be for it to be closed faster, so a waiting period would go against that. Couldn't a steward just close it in the first 24 hours then? And if a steward hasn't closed it after 24 hours, what's the harm then? Does that mean nobody saw it or a steward explicitly decided not to close it? Naleksuh (talk) 13:31, 6 April 2023 (UTC)

Proposal 3
The penultimate paragraph is amended as follows:

Stewards may overturn any user closes if they believe that they are made in error. Meta Bureaucrats may overturn any user closes which concern local permission requests.

Support

 * 1)  as proposer. DeeM28 (talk) 15:53, 4 April 2023 (UTC)
 * 2)  BrandonWM (talk • contributions • global • rights) 00:20, 5 April 2023 (UTC)
 * 3)  Collei (talk) 05:45, 7 April 2023 (UTC)

Comments

 * An unlikely scenario, but another necessary request for clarification before support: Say a steward closes under this policy and a Meta bureaucrat disagrees.  Is the Meta Bureaucrat empowered under this clause to overturn the steward's closure? --NotAracham (talk • contribs • global) 00:52, 6 April 2023 (UTC)
 * Stewards would have the ultimate authority but the reason for this minor change is that right now the implication of the policy is that a Meta bureaucrat would not be able to overturn a user close for a Meta administrator permission request. --DeeM28 (talk) 10:05, 6 April 2023 (UTC)


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