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)

Comments

 * 1) As noted in the last comment section I would be interested in knowing what example prompted this as I would think/hope this is already standard practice and I would like to follow it/see it followed going forward if there have been slips. I think it's a perfectly good suggestion to make regardless of its presence in policy or RfC. This proposal otherwise seems reactionary in nature. --Raidarr (talk) 14:21, 21 May 2023 (UTC)
 * Most recent example: Requests for Comment/Wiki governance and local elections where at least one user other than me asked a question which went unanswered despite the closing Steward being the same as the proposer. This has happened before so if you need more examples, I am confident I can find them. Redmin Contributions CentralAuth (talk) 14:51, 21 May 2023 (UTC)
 * I think I see what you mean, unfortunately. This plays into a larger issue I have with the nature of RfCs here once they enter the voting process, where discussion typically dies at scale and suggestions inline rarely get anywhere even if they may be a substantial compromise. When added after launch, new suggestions are lost by the voting base and there is rarely an effort to thoroughly explore options once a few things are on the table. When proposals become extravagantly long it is almost hard to blame people as there becomes infinitely more to read all on the same page, sometimes with little structure. Another gripe I have even here is that discussion like this will substantially lengthen the page even if put in pre-vote collapse boxes.
 * There are two ideas I'd like to discuss, in the spirit of my gripe maybe in its own section or elsewhere, which would hopefully also ensure Stewards do not miss interesting discussion items. One is to alter the drafting stage so it encourages discussion on the issues but discourages simple 'voting' until a second stage, where a more complete array of items can be 'voted on' unless the outcome is very obvious in the first stage (ie: everyone agrees in the informal discussion stage and the issue is too small to delay with another stage). This would make RfCs two part and encourage discussion to make things in their best form rather than 'here it is, take it or leave it'.
 * Another is to encourage more freeform discussion on a topic through its talk page or even subpages if large enough while keeping the central page a somewhat cleaner hub, with active encouragement of participants who care to discuss. In other words - make the RfC a hub and encourage longer form discussion throughout the process, but not drowning the main page in it.
 * The goal in either case is to reduce the pure 'voting culture' where sheer numbers and 'per xyz' dominate the process, a problem which I believe exists at all levels from non-functionary voters to closers who are incentivized to 'keep it simple' and go by voting as compared to maximizing discussion and making policy suggestions/proposal text the best form they can be. These are very rough ideas not even meriting my own draft RfC on the matter, but I hope my angle on this is somewhat clear. --Raidarr (talk) 09:57, 22 May 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)
 * I think for this proposal it would be best to identify a current example of what you would consider an existing meaningful IP editor to account as an impactful vote. Miraheze has a far weaker IP editing culture than Wikipedia and doesn't tend to take all the same cues, so I would imagine examples as well as passion for this would be more difficult to find native to this platform. --Raidarr (talk) 14:20, 21 May 2023 (UTC)
 * If I am being honest during my time on Meta I have not seen any IP address that could be described to me as engaging in "meaningful" edit by any possible interpretation of that word. In addition I believe that any attempt at a definition would be too subjective and involve too much pressure on the part of a Steward to decide whether to allow a vote or not based on a clearly subjective and impossible to assess objectively criteria. I have said that I would not comment on the substance of this proposal but I must say that it is simple for any person to create an account and I cannot see why there is a necessity for the introduction of such a subjective based test for comments to be counted as "votes". DeeM28 (talk) 14:23, 21 May 2023 (UTC)
 * For both you: it makes sense for Meta not to get enough IP edits, in my opinion. This wiki serves as a central hub for users. The editors I have in mind are those who edit "content wikis", who definitely exist out there.
 * For DeeM28: "it is simple for any person to create an account" - you are obviously right but the RfCP states- "Users who created their accounts after a Request for Comment has been published may not vote in that Request for Comment. Such users 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'." Redmin Contributions CentralAuth (talk) 15:04, 25 May 2023 (UTC)
 * If I might add, this proposal does seem to create a sort of loophole in the rule that says users who created their accounts after the RfC can't vote. This would then essentially allow those users to vote in limited circumstances from their IP address and therefore almost be an advantage to users who aren't registered. Reception123 (talk) ( C ) 15:07, 25 May 2023 (UTC)
 * Redmin's wording provides for an exception when ip editors have a meaningful history, which can logically fit with the current rule on accounts: verifiable IP identities with a meaningful history may be expected to have participated longer than the runtime of the RfC. If the history they point to is newer, then I would consider the exception to be inapplicable. Though, this comes back to DeeM's concern of the wording being too vague in the first place since my theory is purely interpretive and can lead to counterarguments about recent meaningful editing history (where does one draw the line for meaningful anyway) and the fact it requires a potentially inconvenient investigation into exactly what wiki such a meaningful history is on. To my knowledge there is no IP central nexus to refer to as exists for accounts. --Raidarr (talk) 15:44, 25 May 2023 (UTC)
 * "recent meaningful editing history" Good point; suggestions are, as always, welcome. "To my knowledge there is no IP central nexus to refer to as exists for accounts." That is probably the biggest issue with this proposal. Do you think requiring commenting IPs to specify where they contribute would be enough? Redmin Contributions CentralAuth (talk) 15:10, 26 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)
 * That satisfies my concerns, @Raidarr, @NotAracham and @DeeM28. What prompted me to make this proposal is the close of the original RfC about RfCP, which is highly confusing to read through. But as that appears to have been an outlier, I think I am going to move this to the bottom of the page and collapse it when voting begins. Thanks. Redmin Contributions CentralAuth (talk) 13:47, 21 May 2023 (UTC)
 * had a particular way of closing that would be best to inquire with him directly if it is unclear. --Raidarr (talk) 14:17, 21 May 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)

Proposal 5.1: Closure (14 day alternative)
'Requests for Comment that affect the global community must generally stay open for at least fourteen (14) 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: Per encouragement to do so from Redmin, I've drafted a 1:1 equivalent of proposal 5, with the sole superseding change being a reduction from 20 days to 14 for globally-scoped RfCs. As mentioned in my earlier comments, conversation and voting on the majority of globally-scoped RfCs are usually long-over by two weeks from open and Stewards have exercised appropriate discretion in the past to keep RfCs open when conversation is ongoing past that point.

In my view, this version strikes an appropriate balance between keeping impactful RfCs open long enough for meaningful community review and input while avoiding artificial/excessive delay of RfC closure. --NotAracham (talk • contribs • global) 19:34, 24 May 2023 (UTC)

Support

 * 1)  as proposer. --NotAracham (talk • contribs • global) 19:34, 24 May 2023 (UTC)