Requests for Comment/Changes to Requests for Comment Policy

__NEWSECTIONLINK__ Changes made to existing clauses have been highlighted by italicisation. Redmin Contributions CentralAuth (talk) 22:27, 18 April 2023 (UTC)

Proposal 1: Closure When There Are Unanswered Questions
'''If a relevant functionary wants to close a Request for Comment that has unanswered questions, they should ask the proposer(s) to respond in such a way that the proposer(s) get notified (e.g. by use of the  template, sending email(s) etc.). However, if the closing functionary is (one of) the proposer(s) then they must get the questions answered (by themselves or if there are multiple proposers then by one of the co-proposers) before closing it. In both cases, if the questions get answered then the functionary must wait for a reasonable duration to allow the user who asked the question to vote accordingly.'''

Rationale: It is unfair to the user who asked a question that got ignored when Stewards (or local bureaucrats) close RfCs without giving them a chance to vote and even more so when they (the closing Steward) are one of the proposers.

Support

 * 1)  as proposer. Redmin Contributions CentralAuth (talk) 22:27, 18 April 2023 (UTC)

Proposal 2: IP Comments
'''Only registered users may initiate or vote in Requests for Comment. Unregistered users (IPs) may participate in Requests for Comment by way of comments, but these will not ultimately be considered when deciding consensus and will not count as 'votes'. Exceptions will be made to this rule for those IP addresses which are clearly being used for meaningful editing.'''

Rationale: Wikipedia has a nice essay regarding this. Meaningful editing could be defined as edits on Meta and "content wikis".

Support

 * 1)  as proposer. Redmin Contributions CentralAuth (talk) 22:27, 18 April 2023 (UTC)

Comments

 * 1)  While not wanting to comment on the actual proposal as that should be reserved for when it is open I wanted to mention that without a more clear definition of "meaningful" this is likely to be rejected as too vague as this usually happens whenever a vague notion is introduced into RfCs.--DeeM28 (talk) 14:03, 17 May 2023 (UTC)
 * Please do suggest a definition if you are interested. Redmin Contributions CentralAuth (talk) 12:59, 21 May 2023 (UTC)

Support

 * 1)  as proposer. Redmin Contributions CentralAuth (talk) 22:27, 18 April 2023 (UTC)

Comments

 * 1) I would comment here that from the title of this proposal I think that there is a misconception about the process of closing RfCs on the part of the initiator. I would ask people with more knowledge to correct me if I am wrong but I have always understood that an RfC proposal is not closed as successful if there are 51% support votes but rather the comments are carefully taken into consideration and if there is not a strong sense of support or consensus it will not be deemed as successful. I have seen in the past RfC where there was even a 55%-60% support ratio and it was unsuccessful. I do not think it is pertinent or necessary to introduce ratios to the realm of RfCs where consideration of the strength of arguments is one of their main advantages. I apologize if I have gone too much into an area of substance rather than comments on the draft itself. --DeeM28 (talk) 18:41, 28 April 2023 (UTC)
 * Seconding DeeM28's understanding of how narrow votes are already handled -- simple majority does not always (and frequently doesn't) mean successful closure. Without content it's hard to know exactly what's being proposed here, but it seems like a solution in pursuit of an already-solved problem... NotAracham (talk • contribs • global) 21:05, 28 April 2023 (UTC)
 * I seek a support ratio of 60-70% modified by arguments at play, on the lower end if argumentation heavily lopsides towards support and higher if towards opposing arguments, 66 in cases of a clean split. I do not accept 50 to 59 as a consensus, rather as evidence of clear and severe division. My inclination in that case would be towards the 'no change' option until whatever caused that proposal to be so divisive is resolved. But like most of the proposals here the actual intention and angle of the header is unclear and unexplained. I'm not sure it was ideal to have this draft in the mainspace as it is too unformed to even comment; perhaps in the userspace it would have had more 'shroud' to be formulated before comments like these appear. --Raidarr (talk) 09:59, 29 April 2023 (UTC)

Proposal 4: Use of Discussion Tools
'''Use of Discussion Tools on Requests for Comment pages is encouraged to make replying to and adding new proposals easier and less time-consuming. This is to be done with the addition of .'''

Rationale: This probably does not need to become an official policy but given this is usually not done, it may be useful to revive this old practice from 2021 even if it was never used on all RfCs.

Support

 * 1)  as proposer. Redmin Contributions CentralAuth (talk) 15:09, 23 April 2023 (UTC)

Proposal 5: Closure
'Requests for Comment that affect the global community must generally stay open for at least twenty (20) days; and those that affect local communities (e.g. Meta, Login Wiki etc.), must generally stay open for at least five (5) days''. They can be closed before either if they are out-of-scope, malformed, if it is clear that there is no chance of consensus, or if there is an emergency. A Request for Comment that has not been drafted in advance may be closed by a Steward immediately if it is too vague or unclear.'''

Rationale: A five day limit is too small for a community the size of Miraheze; I would have gone for thirty days if there were not cases were a lot of comments were made within five days justifying a Steward closure. The addition of the exception for cases where there is an emergency is for cases like the move to Libera.Chat for Miraheze's IRC channels nearly two years ago.

Support

 * 1)  as proposer. Redmin Contributions CentralAuth (talk) 15:09, 23 April 2023 (UTC)

Comments

 * Fully aware you're still in drafting stage here, but may I suggest 14 days as a reasonable minimum on globally-scoped RfCs instead? Reviewing previous RfCs, most conversations have well-petered out by that point and Stewards generally don't close global RfCs before then anyhow (or if there's active discussion/voting still underway).  Keeping open for a full 20 days in the case of a clear consensus supporting with 0 opposes seems excessive, in my view... --NotAracham (talk • contribs • global) 17:34, 23 April 2023 (UTC)
 * Feel free to add any alternatives or amendments. The reason behind choosing 20 days is quite personal. I was unaware of the "recent" wiki governance RfC due to inactivity and only came to know about it more than a month after it was opened (and voted on it about half a month later due to my question on the RfC never being answered). Had a Steward closed it as soon as active discussion had ended, I would not have been able to participate there and I doubt I am the only local admin who feels the current limit is far too small and fails to take into account that most people have IRL commitments. Having said that, I do agree that if there is a clear consensus, it makes absolutely no sense to keep an RfC open for that long so if you have any wording changes in mind, I would gladly change this proposal (without introducing any amendment). Redmin Contributions CentralAuth (talk) 19:31, 23 April 2023 (UTC)
 * What I might suggest is that you add the Requests for Comment page to your watchlist so that you are able to receive notifications when a new one is added. Even though I disagree and have made this clear before with RfC being closed immediately after the minimum period has expired for no particularly urgent reason I would agree with NotAracham that 20 days is too much for a minimum period. It is unfortunate that some people might miss RfCs but if users are interested in voting in RfCs they are free to use the watchlist method to get notified immediately. I would be willing to support a similar proposal if the concept was reversed and the norm would remain 7 days but the exception for "major reform RfCs" would be a longer period such as 14 days or 21 days but there are also arguments against this which is that it would be hard to differentiate this new "type" of RfC. DeeM28 (talk) 18:38, 28 April 2023 (UTC)
 * What kinds of proposals would "the norm" cover? We already differentiate between RfCs in that they can either be global or local so while this particular way of differentiation would indeed be new, it would not exactly be unprecedented. Redmin Contributions CentralAuth (talk) 16:47, 7 May 2023 (UTC)
 * I concur with the suggestion to keep tabs on the RfC page more closely, as I think 2 weeks is an easily reasonable time in most cases. The only issue on this front I see is a bit of closing inconsistency, sometimes the RfCs are closed a little abruptly and other times they drag on a bit. In other words mainly a consistency issue if any is at play here.
 * Perhaps suggestions can be made to increase actual participation and traction. Regardless if an RfC sits for months, certain RfCs obviously have far more traction than others. Anything particularly of interest or controversial seems to find its own attention but more clerical RfCs have dragged on and on with only one or two votes trickling in that minimally affect the outcome. I'd like to see more engagement from wiki 'stakeholders' on RfCs and the going-ons of Miraheze in general. Some people will never care but the rights and influence of wiki operators are rarely understood. I find that Meta represents a minimal sample of the global community. That is something that should be addressed on its own terms, and this proposal would do little. It doesn't make people pay more attention or incentivize engagement. It just enforces the procedural difficulties of resolving RfCs in a timely manner.
 * There's not much to comment on for the overall RfC as not even a minimal rationale or explanation exists for the rest of the proposals though. --Raidarr (talk) 09:51, 29 April 2023 (UTC)
 * Are there any plans to move this draft further or open the RfC? I think that it would be better to only bring drafts into the main Requests for Comment space when they are somewhat ready so as to not have them be present in "Draft requests" for weeks without any activity. DeeM28 (talk) 15:03, 5 May 2023 (UTC)
 * Please have some patience. It has only been a week since you posted that message; people have lives, and I am no exception. Also, I am merely following the instructions on the RfC page in creating this in the main space. Redmin Contributions CentralAuth (talk) 16:22, 5 May 2023 (UTC)
 * I apologize for the impression given. I did not mean to rush you but merely wanted to confirm that you had not forgotten about this draft. I still believe that as a general rule it would be preferable for drafts to only be publicised in the main namespace after they are ready for comment. DeeM28 (talk) 14:01, 17 May 2023 (UTC)
 * I think you'd be referring to the soft convention of drafting in userspace. It is my preference and others hold it too, but the mainspace draft is encouraged by how the RfC page is set up: put in a title, create, end up with a page premarked as a draft and go from there. It's not instructed to go this way but it is intuitively set up that way. Perhaps this can be discussed in its own venue to see if we can arrange a stronger practice become the default. From a philosophical perspective I think the RfC process is a little broken and in need of rethinking anyway. This draft is so sweeping as to encourage a bit of a 'from the basics' rethinking of how RfCs are formed and I'd actually prefer an arrangement where open community discussion to form coherent policy ideas is strongly encouraged before ratifying 'votes' (which, despite my inexperience with Wikimedia, seems it's already a perversion of the practice Miraheze was inspired by).
 * There is not a bigger picture approach in the process and I think that's a shame. I believe this RfC would benefit from being prefaced by a broader opening which expresses the issues this RfC would want to address, from which specific remedies can be found and then molded into writing that fits into and evolves platform policy rather than being a singular effort tempered by off 'unofficial' comments on the sideline. Simply drafting out sections the way it's done now with people already forming camps, and policy discouraging substantive discussion from the start is something I've come to see as a potentially serious block on progress. For example the newly fleshed out proposal 1 is something I'd want to take as a direct suggestion and discuss on its face, including examples where Stewards have neglected to follow that reasonable process properly and how we can do better. --Raidarr (talk) 14:45, 17 May 2023 (UTC)