Requests for Comment/Changes to Requests for Comment Policy
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.
- This Request for Comments has been open for a while now and is closed as follows:
- Proposal 1: Unsuccessful
- Proposal 2: Withdrawn
- Proposal 4: Unsuccessful
- Proposal 5: Unsuccessful
- Proposal 5.1: Successful
- Proposal 5.2: Successful
- Proposal 5.3: Unsuccessful
- Proposal 5.4: Withdrawn
- Proposal 6: Successful
- Proposal 7: Unsuccessful
- Agent Isai Talk to me! 02:24, 10 March 2024 (UTC)
- This Request for Comments has been open for a while now and is closed as follows:
This RfC aims to improve the current Requests for Comment Policy as it may not be doing enough; details are in the proposals themselves. Proposal 3 has been "hidden" as I have chosen not to include it in the live version of this RfC as others have correctly pointed out that what I hoped to achieve with it is already the status quo. Changes made to existing clauses have been highlighted by italicisation; the parts that are in bold (with no italicisation) are additions. I would like to thank DeeM28, NotAracham and Raidarr for providing input and guiding me through the process of creating this. Redmin Contributions CentralAuth (talk) 22:27, 18 April 2023 (UTC)
- No votes other than the initiator's and therefore no consensus. Reception123 (talk) (C) 07:44, 14 January 2024 (UTC)
- I am reopening this based on discussion on Discord as the lack of participation was due to a lack of advertisement of the RfC and diminished interest in Miraheze. Redmin Contributions CentralAuth (talk) 19:15, 22 January 2024 (UTC)
Proposal 1: Closure When There Are Unanswered Questions[edit | edit source]
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 {{ping}}
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[edit | edit source]
- Support as proposer. Redmin Contributions CentralAuth (talk) 22:27, 18 April 2023 (UTC)
- Support Accountability. --NimoStar (talk) 14:14, 13 February 2024 (UTC)
Abstain[edit | edit source]
Oppose[edit | edit source]
- Strong oppose the decree around unanswered questions is too broad and open to abuse, in my view. It is already established best practice to leave RfXs with active, good-faith discussion open, and the scant exceptions I've seen were otherwise already decisive or being monopolized by single individuals for various reasons. --NotAracham (talk • contribs • global) 20:05, 22 January 2024 (UTC)
- Oppose I don't think administratively closing an RfC due to unanswered questions is appropriate. The community can decide to support or oppose based on the RfC and their view of the significance of the proposer's not answering questions. – Jph2 (talk) 00:06, 23 January 2024 (UTC)
- Oppose per NotAracham. I don't think it's necessary to empower single individuals like this as it's open to abuse. If there has been good faith engagement with questions and there's already a consensus for a proposal it seems strange that it shouldn't be closed. Reception123 (talk) (C)
- Oppose I do not wish to write at length on this subject as it not fully relevant but for people who are familiar with the filibuster procedure that exists in the United States Senate this proposal seems to more or less replicate its function. This proposal is worded in such a way that would allow any single user the possibility to demand answers to every question even if there is a large democratic majority in favor of the proposal and thus prevent its adoption. I do not believe that this is desirable as in any debate there will be users who disagree but that does not mean that the proposer should be mandated to engage with them indefinitely. To give an example it would not be inconceivable for me to ask a different question related to this proposal every day and to delay it in this way. In essence I do not believe that unanswered questions is as much of an issue as the proposer suggests. --DeeM28 (talk) 13:33, 23 January 2024 (UTC)
- Oppose Too far open to abuse, and Dee and NotAracham's responses essentially sum up my argument. BrandonWM (talk • contributions • global • rights) 01:15, 30 January 2024 (UTC)
- Oppose Per above. --Blad (t • c • g) 17:56, 2 February 2024 (UTC)
- Oppose Per NotAracham. Globe - (Talk • Contributions • CA) 14:29, 23 February 2024 (UTC)
- Oppose per others, also if there were unanswered questions under current policy these wouldn't be material to the RfC and could be discussed in other places Collei (talk) (contribs) 20:33, 24 February 2024 (UTC)
- @Collei, where do you see "unanswered questions under current policy" being discussed on this RfC except under the (collapsed) comments section before where it was only brought up to explain what prompted me to make this proposal? Redmin Contributions CentralAuth (talk) 14:08, 28 February 2024 (UTC)
Comments[edit | edit source]
Extended content |
---|
|
Proposal 2: IP Comments[edit | edit source]
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
- Withdrawn due to important arguments raised by DeeM28 and Harej. Redmin Contributions CentralAuth (talk) 07:09, 24 January 2024 (UTC)
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, in which case it is the responsibility of the IP editors to explicitly mention which wiki(s) they contribute to.
Rationale: Wikipedia has a nice essay regarding this. Meaningful editing could be defined as edits on Meta and "content wikis".
Support[edit | edit source]
- Support as proposer. Redmin Contributions CentralAuth (talk) 22:27, 18 April 2023 (UTC)
Weak support Frankly, this is a bit confusing. The heading suggests ignoring comments from non-logged-in persons (IPs) but the verbiage seems to tolerate comments by all. I am in favor of meaningful discussion by all interested parties, including registered and unregistered (IP) users, as beneficial. But votes, for purposes of determining consensus, should be limited to logged-in users who were users-of-record, so to speak, before the date the RfC went "live". – Jph2 (talk) 00:15, 23 January 2024 (UTC)- To clarify, the first half of this proposal is already policy, the second half (which is the actual proposal here) is to make an exception to *allow* for logged-out IP editors to vote, as I read it. @Redmin, can you clarify the intent with this proposal? --NotAracham (talk • contribs • global) 00:29, 23 January 2024 (UTC)
- Definitely need the clarification. There's a big difference logged-out (IP) comments and voting, which should only be logged-in users, imho. Pending clarification, that may change my vote. – Jph2 (talk) 01:34, 23 January 2024 (UTC)
- NotAracham is right, the intent is to allow IP editors to vote. Redmin Contributions CentralAuth (talk) 18:25, 23 January 2024 (UTC)
- Definitely need the clarification. There's a big difference logged-out (IP) comments and voting, which should only be logged-in users, imho. Pending clarification, that may change my vote. – Jph2 (talk) 01:34, 23 January 2024 (UTC)
- I am changing my position from support to oppose based on this clarification. As noted in my original vote, I don't support IP voting. – Jph2 (talk) 21:56, 23 January 2024 (UTC)
- To clarify, the first half of this proposal is already policy, the second half (which is the actual proposal here) is to make an exception to *allow* for logged-out IP editors to vote, as I read it. @Redmin, can you clarify the intent with this proposal? --NotAracham (talk • contribs • global) 00:29, 23 January 2024 (UTC)
Abstain[edit | edit source]
Oppose[edit | edit source]
- Strong oppose this is a solution in search of a problem, in my view. The very WP essay you link to includes a thorough rationale for why IP editors should not be allowed to vote. --NotAracham (talk • contribs • global) 19:55, 22 January 2024 (UTC)
- Oppose per NotAracham Commetian Empire (talk°•◇•°CentralAuth) 22:10, 22 January 2024 (UTC)
- Oppose I think this opens up a clear risk of sockpuppetry as anyone could just use their IP to make some meaningful edits and then vote. Not to mention that creating an account is very easy and doesn't even require an email, so if someone is that engaged to want to vote in an RfC, there's little reason for why they shouldn't take the minimal step to create an account. Reception123 (talk) (C) 11:56, 23 January 2024 (UTC)
- "a clear risk of sockpuppetry as anyone could just use their IP to make some meaningful edits and then vote"Except the RfCP prevents anyone who made their account after the RfC was created from voting which would apply here as well. And that's also why "creating an account is very easy and doesn't even require an email" does not actually help these people. Redmin Contributions CentralAuth (talk) 18:30, 23 January 2024 (UTC)
- Strong oppose It might be the case that this is a more radical view that I hold but if there was agreement I would not hesitate a proposal to ban IP editing in its entirety. As pointed out in the comments above there is little difficulty in creating an account and I do not think there are compelling reasons to choose not to create an account. Multiple users can edit from the same IP if it is located in a public place such as a library so this proposal would present an issue just from that. --DeeM28 (talk) 13:35, 23 January 2024 (UTC)
- Multiple users can edit from the same IP if it is located in a public place such as a library so this proposal would present an issue just from that.Well, that's a great argument, and along with Harej's comment below convinces me to withdraw this proposal. If Jph2 agrees, I am going to go ahead and do that. Thanks for pointing this out. Redmin Contributions CentralAuth (talk) 18:35, 23 January 2024 (UTC)
- Oppose While I support IP editors being able to ask questions and make comments, I believe only logged-in users should be able to vote. There is no way to determine if an IP editor was part of the project before an RfC was posted. In the past, "eligible voters" has meant registered users with accounts dating from the RfC posting or earlier. – Jph2 (talk) 21:56, 23 January 2024 (UTC)
Comments[edit | edit source]
- "Clearly being used for meaningful editing" is too vague to build a policy around. More to the point, this makes it too easy for someone to cast a vote logged in, then log out and vote again. IPs are human, but as that linked essay points out, their ability to meaningfully comment does not extend to being able to vote in a one-person-one-vote system. Harej (talk) 22:22, 22 January 2024 (UTC)
Extended content |
---|
|
- The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Proposal 3: Result When a Proposal Has Equal Support and Opposition[edit | edit source]
Extended content |
---|
Support[edit | edit source]
Abstain[edit | edit source]Oppose[edit | edit source]Comments[edit | edit source]
|
Proposal 4: Use of Discussion Tools[edit | edit source]
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 __NEWSECTIONLINK__
.
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[edit | edit source]
- Support as proposer. Redmin Contributions CentralAuth (talk) 15:09, 23 April 2023 (UTC)
Abstain[edit | edit source]
- I support the tools being implemented at earliest convenience, I am swayed by the argument that it does not need to be codified formally. --raidarr ( 💬 ) 22:50, 19 February 2024 (UTC)
Oppose[edit | edit source]
- Weak oppose agreed that improvements to RfC boilerplate would be helpful to standardize, but not convinced this approach needs to be codified policy... --NotAracham (talk • contribs • global) 20:24, 22 January 2024 (UTC)
- Oppose If it "probably doesn't need to become an official policy", then it probably shouldn't. On top of that, it seems to me the average RfC is somewhat over-complicated to begin with (witness this one which has 4 or 5 proposals as it is). I'm concerned using discussion tools to facilitate more variant proposals will complicate matters to the point an RfC will collapse under its own weight. – Jph2 (talk) 00:24, 23 January 2024 (UTC)
- Procedural Oppose I do not disagree with the recommendation but as it has been pointed above I do not believe that recommendations are something that need to be codified or voted on. --DeeM28 (talk) 13:37, 23 January 2024 (UTC)
- Procedural Weak oppose I am in full agreement with the recommendation and would propose to Stewards that it is implemented immediately, but don't think it needs to be codified. BrandonWM (talk • contributions • global • rights) 01:17, 30 January 2024 (UTC)
Comments[edit | edit source]
- Principally I tend to worry more about how addon proposals are neglected because they've showed up too late to the proverbial voting party. This issue will dominate addon proposals regardless of it being made easier to do (and as some of our more gnarly RfCs demonstrate this isn't always desired either). In any case this is something that should probably just be advised to people who are drafting RfCs so it can be integrated early. I will second the 'probably doesn't need to become an official policy' in the proposal text. --Raidarr (talk) 21:31, 28 May 2023 (UTC)
- This already says "encouraged"; do you have something better in mind? Redmin Contributions CentralAuth (talk) 15:46, 30 May 2023 (UTC)
- Requiring the use of a specific software tool does not seem like an appropriate use of policy. Harej (talk) 22:23, 22 January 2024 (UTC)
Proposal 5: Closure[edit | edit source]
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[edit | edit source]
- Support as proposer. Redmin Contributions CentralAuth (talk) 15:09, 23 April 2023 (UTC)
Abstain[edit | edit source]
- Abstain While I agree 5 days is too short for the global community, I'm not sure what "local communities" means here. If it's Meta and Login, I think the same timeframe as the "global community" should apply, since its the same audience. If "local communities" is individual wikis, then that should be their call. – Jph2 (talk) 00:35, 23 January 2024 (UTC)
Oppose[edit | edit source]
- Oppose Closure is already well-governed by rules around active conversations and RfCs are regularly left open for more than the required minimum already, especially when there is active, good-faith conversation. Forcing an arbitrary minimum of 20 days seems counterproductive when vanishingly few RfCs receive much activity past 14 days when left open past that point. Accordingly, I've added an alternative proposal of 14 days, but it's my view that neither is necessary at this time. --NotAracham (talk • contribs • global) 22:27, 22 January 2024 (UTC)
- Oppose per NotAracham. In my experience there's certainly cases where there is a clear (even unanimous) consensus and there's really no need to wait and prevent implementation. If there is some dissent, I don't think I've ever really seen an RfC being closed after 5 days. I don't think we need an arbitrary date as Stewards can use their discretion to determine this. Reception123 (talk) (C) 11:59, 23 January 2024 (UTC)
- Weak oppose I believe that the term proposed in Proposal 5.1 is to be preferred to this one as a good alternative to the current 5 days. --DeeM28 (talk) 13:42, 23 January 2024 (UTC)
- Oppose per NotAracham. We don't need to push the closure if almost all RfCs last longer than it. Commetian Empire (talk°•◇•°CentralAuth) 22:05, 23 January 2024 (UTC)
- Oppose per NotAracham in this case. Most RfCs lose their activity within a week or so, maximum. BrandonWM (talk • contributions • global • rights) 01:18, 30 January 2024 (UTC)
Comments[edit | edit source]
- For your information, I am also working on a proposed policy for advisory RFCs which are like formal requests to the Board. In this policy I call for a discussion and drafting period of 4-21 days, and a draft freeze and vote period of 7 to 14 days. As a combined time period this would make advisory RFCs between 10 and 35 days, and your proposal falls within that range. Harej (talk) 22:28, 22 January 2024 (UTC)
Extended content |
---|
|
Proposal 5.1: Closure (14 day alternative)[edit | edit source]
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[edit | edit source]
Support as proposer. --NotAracham (talk • contribs • global) 19:34, 24 May 2023 (UTC)- Support For exactly the reasons stated in the rationale. I think 5 days is too short for global RfCs. I also think a minimum timeframe is appropriate to ensure the community has the opportunity to weigh in. It doesn't really matter if the difference between 5 or 14 days results in increased participation in the RfC since the issue is really the ability to participate. A two-week period gives ample opportunity for those who choose to participate to do so even if they are not online every day. Absent an "emergency" situation, the wait for concluding an RfC in 14 days vs. just 5 is not overly significant but the increased participatory period matters. – Jph2 (talk) 00:55, 23 January 2024 (UTC)
- Support Even if in principle I am trusting of Steward discretion in this area I cannot ignore the fact that there can indeed be a tendency to want to close requests very soon after their deadline. I agree that 5 days for any RfC is not sufficient and a 14 day time period would be preferable and would allow users who are not following this page an opportunity to vote. If given a flexible interpretation I believe that the term emergency' is able and should accommodate all situations where waiting longer would either undermine the proposal or would have negative effects. --DeeM28 (talk) 13:40, 23 January 2024 (UTC)
- Weak support Redmin Contributions CentralAuth (talk) 07:00, 30 January 2024 (UTC)
- Support for similar grounds as Jph2. It sounds reasonable, overall. Kourouklides (talk) 08:03, 2 February 2024 (UTC)
Abstain[edit | edit source]
- Neutral Revisiting this, I really don't think any timeframe is necessary, but leaving it unopposed in case others prefer this option. --NotAracham (talk • contribs • global) 22:28, 22 January 2024 (UTC)
- Neutral I think 14 days is a fair period but I think the word "emergency" without any examples is too vague. For example, one could've argued that adopting the translation RfC was an emergency to quickly put an end to poor quality translations on Meta but someone else could easily disagree. Reception123 (talk) (C) 12:01, 23 January 2024 (UTC)
- Abstain I really don't think a minimum timeframe is necessary. BrandonWM (talk • contributions • global • rights) 01:19, 30 January 2024 (UTC)
Oppose[edit | edit source]
Comments[edit | edit source]
Extended content |
---|
|
Proposal 5.2: Early Closure[edit | edit source]
A Request for Comment may be closed early with no outcome, if, in the closer's discretion, the Request for Comment is found to have an insufficiently formed problem statement, is beyond the scope or capacity of the community, is extremely unlikely to result in a tangible outcome, or is otherwise a misuse of the process. Requests for Comment may also be withdrawn by the initiating drafter if all participants do not object to such action.
Rationale: Getting consensus for this separately from duration. Harej (talk) 20:07, 25 January 2024 (UTC)
Support[edit | edit source]
- Weak support this is already implicit policy, but no harm in officially codifying it I suppose. --NotAracham (talk • contribs • global) 21:09, 26 January 2024 (UTC)
- Support It makes sense to me to codify this to support transparency and understanding. – Jph2 (talk) 22:10, 26 January 2024 (UTC)
- Support per NotAracham. Redmin Contributions CentralAuth (talk) 16:23, 28 January 2024 (UTC)
- Support Sure? This is already what's done. BrandonWM (talk • contributions • global • rights) 01:20, 30 January 2024 (UTC)
- Support As it has been said above this is already the case but it is welcome to have more clear language regarding this. --DeeM28 (talk) 11:50, 31 January 2024 (UTC)
- Support for similar grounds as Jph2. Kourouklides (talk) 07:54, 2 February 2024 (UTC)
Abstain[edit | edit source]
Oppose[edit | edit source]
Comments[edit | edit source]
Proposal 5.3: Comment Period[edit | edit source]
Requests for Comment particular to Meta or a specific wiki must be scheduled for at least seven (7) days. Global Requests for Comment must be scheduled for at least 14 days. The end period of the Request for Comment must be written in advance on the Request for Comment. Having a deadline prompts people to act within a certain timeframe. However, the end date can extended at any time to allow more time for comments.
Rationale: Rather than have RFCs slog on indefinitely, they should take place within concrete timeframes, giving more urgency to the matter. At the same time we should be flexible with these timeframes. Harej (talk) 20:07, 25 January 2024 (UTC)
Support[edit | edit source]
- Support as an alternative to 5 (which most likely won't pass). Redmin Contributions CentralAuth (talk) 17:02, 28 January 2024 (UTC)
Abstain[edit | edit source]
- Abstain In principle, I strongly agree with the comment period to end based on a predefined condition, such as a deadline or a dynamic milestone (e.g., after at least 10 members have voted) or a combination of the two (e.g., <Condition A> or <Condition B>, whichever occurs first), so that there can be no excuses or concerns regarding the level of engagement. It would be much clearer and more transparent than now. Also, there are enough data (e.g., average, minimum and maximum number of participants in each proposal) to now codify this. If immutable and predefined, I would like the proposer to actually have a say on this (before voting begins). However, the wording of the current proposal is very badly written in the sense that it is confusing, unclear and ultimately questionable if useful at all. Therefore, even though I am not neutral, I abstain. Kourouklides (talk) 08:24, 2 February 2024 (UTC)
Oppose[edit | edit source]
- Oppose This is another variant on the other closure periods (5, 7, 14, or 20 days depending on which 5-series proposal you look at). I do agree it makes sense for RfCs to state their open period as a best practice, however, although it probably doesn't need to be policy. – Jph2 (talk) 22:17, 26 January 2024 (UTC)
- Weak oppose it's a sensible suggestion, but it's difficult (as this RfC's history makes clear) to determine level of voter participation ahead of time and when consensus can reasonably be reached. For this reason, requiring a maximum within certain bounds as policy doesn't seem like the best way to proceed. --NotAracham (talk • contribs • global) 23:56, 27 January 2024 (UTC)
- What are your thoughts on requiring a minimum open period, but not a maximum? This would disallow someone from railroading an RFC through approval, but it would not disallow RFCs from taking a long time as they seem to naturally do. Harej (talk) 18:10, 28 January 2024 (UTC)
- The lingering open state is definitely an issue, though was much less of a problem in the period where we had multiple concurrent serving stewards to allow for timely and unconflicted closes. The problem now with the reduced activity on Meta is reaching a large enough voting pool for RfXs to reasonably be called a consensus.
- The idea of instilling urgency with a hard deadline makes sense, but only from a perspective of an already-engaged userbase, which is the problem we have -- discoverability and global engagement are both fairly low, both historically and especially at present. Some ideas off top of mind...
- Discoverability:
- could be solved somewhat by
- adding some other more-visible indicator throughout meta, e.g. something on main page or footer
- perhaps a meta-specific site notice alerting folks to a newly opened RfC
- an opt-out notification when new RfCs are launched
- Labster had some implementation ideas on this front...
- Global Engagement:
- We have channels to promote the existence of new RfCs, we should use them. Some ideas...
- discord announcements for impactful RfCs
- rare global-notices for things like end of year celebrations?
- Social media notices for impactful RfCs/RfC Roundup? (I worry this will bring in IP randos)
- Include language on the on-create mainpage boilerplate that explains a bit about Meta?
- Quarterly state-of-the-platform updates that could act as a pitch for global engagement and volunteer recruitment?
- We have channels to promote the existence of new RfCs, we should use them. Some ideas...
- --NotAracham (talk • contribs • global) 19:29, 28 January 2024 (UTC)
- (And to be 100% clear, I'm not particularly in favor of a prescribed minimum or maximum beyond what already exists, what I more want to drive is ensuring a clear consensus or lack thereof on proposals before they close. --NotAracham (talk • contribs • global) 19:53, 28 January 2024 (UTC))
- What are your thoughts on requiring a minimum open period, but not a maximum? This would disallow someone from railroading an RFC through approval, but it would not disallow RFCs from taking a long time as they seem to naturally do. Harej (talk) 18:10, 28 January 2024 (UTC)
- Oppose No. BrandonWM (talk • contributions • global • rights) 01:20, 30 January 2024 (UTC)
- Weak oppose I am usually a proponent of Steward discretion but in this case I believe that it would be too flexible and it is not immediately clear in what situations it would make sense to derogate from the maximum period defined. It is also not immediately clear how someone would be able to predict the level of engagement and indicate a maximum period in advance. --DeeM28 (talk) 11:52, 31 January 2024 (UTC)
Comments[edit | edit source]
Proposal 5.4: Proposal Freeze[edit | edit source]
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
Withdrawn for being unanimously opposed after over a month. Harej (talk) 23:10, 29 February 2024 (UTC)
Three (3) days prior to the scheduled end date, or seven (7) days for Global Requests for Comment, proposals must be frozen from additional modifications, and no new proposals may be added. This is to ensure all participants have a fair chance to review all proposals available before them without concern for last-minute proposals.
Rationale: We also should do more to make sure people have a fair chance to review and vote on the different options, since options snuck in at the last second have unfair disadvantages (and is unfair to RFC participants as well). Harej (talk) 20:07, 25 January 2024 (UTC)
Support[edit | edit source]
Abstain[edit | edit source]
- Neutral I agree late add-on proposals are unfair to users who may have voted early in the RfC's life. Not everyone comes back to check on how the RfC is doing after their initial review. Those who do may need to consider changing their votes based on the add-on proposals. However, users who suggest late add-on proposals should also recognize their proposal may not gain sufficient traction because it's not timely. I don't see that as unfair, it's just the way it is. – Jph2 (talk) 22:30, 26 January 2024 (UTC)
Oppose[edit | edit source]
- Weak oppose As evidenced by these add-ons, proposals not added very close to the start of voting rarely get adequate interaction or votes to form consensus. There's likely a way to solve it, (and perhaps add-ons, especially large number of add-ons, should be discouraged outright as a community best practice) but I'm not sufficiently convinced that codifying cutoff dates gets us there. --NotAracham (talk • contribs • global) 00:00, 28 January 2024 (UTC)
- Oppose I don't hate the idea, but there's often a case where there's something useful to add. BrandonWM (talk • contributions • global • rights) 01:21, 30 January 2024 (UTC)
- Oppose per BrandonWM. Redmin Contributions CentralAuth (talk) 06:34, 30 January 2024 (UTC)
- Oppose for similar grounds as BrandonWM. Kourouklides (talk) 07:50, 2 February 2024 (UTC)
- Oppose I see what you're trying to go for, but adding an alternative proposal could be a good thing in some cases. Commetian Empire (talk°•◇•°CentralAuth) 23:01, 19 February 2024 (UTC)
Comments[edit | edit source]
- The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Proposal 6: Emergency Actions[edit | edit source]
There are certain scenarios where the action required is so urgent it cannot wait for a Request for Comment to convene. The most notable example of this in Miraheze's history was the migration of IRC channels from Freenode to Libera Chat due to instability in the former. This decision was subsequently ratified by Requests for Comment/IRC.
Stewards and other functionaries may take immediate action on matters, beyond their usual authority, without a Request for Comment only if failing to take such an action would result in immediate service disruption or irreversible harm to Miraheze or to life, limb, or property. Once such an action is taken, a Request for Comment must be opened as soon as it is feasible to. During this Request for Comment, the action needs to be described as well as the circumstances that justified the action. The community will have the opportunity to approve the action without further modification, to modify the action taken, or to undo the action if appropriate. Such a Request for Comment is not necessary if the action taken was within that person's usual authority. Abuse of this process is grounds for sanctions.
Rationale: I'm trying to untangle the emergency thing from the closure thing above. This would create a special policy for emergency situations, defining what those situations are, and how to proceed when such an action is taken. Harej (talk) 20:07, 25 January 2024 (UTC)
Support[edit | edit source]
- Support This is actually status quo to some extent. Redmin Contributions CentralAuth (talk) 17:12, 28 January 2024 (UTC)
- Support Status quo. BrandonWM (talk • contributions • global • rights) 01:22, 30 January 2024 (UTC)
- Strong support "Defining what those situations are, and how to proceed when such an action is taken" is crucial. This is something that should be clear beforehand by including specific examples, for instance. It adds an extra layer of transparency, thus making the community stronger. However, allowing some discretion by the stewards, admin team or whoever is responsible is still equally important, in my view. It just needs to be communicated better. Kourouklides (talk) 07:32, 2 February 2024 (UTC)
- Support De facto IAR and existing practice --Firestar464 (talk) 19:10, 14 February 2024 (UTC)
- Support, I'm sympathetic to the issue of possible overreach and limited examples raised by Redmin but I think this mechanism is safe enough and close to straight reality for well, emergencies like the example of the proposal that it should go fine as written. --raidarr (💬) 13:59, 7 March 2024 (UTC)
Abstain[edit | edit source]
- Abstain The wording of this section is not fully convincing to me and I would only be able to vote if some concrete examples of what constitutes an emergency were provided. --DeeM28 (talk) 11:54, 31 January 2024 (UTC)
Oppose[edit | edit source]
Comments[edit | edit source]
- How does this integrate with board responsibilities, legalities, and foundation policies? It probably makes sense to have a policy in this regard; I'm just not sure if this addresses the various aspects. On top of that, I think it makes sense for this proposal to be a separate RfC rather than being buried in this one on RfC policy. It's more about ratification of an action than it is about the RfC process. – Jph2 (talk) 22:43, 26 January 2024 (UTC)
- Anything involving the WikiTide Foundation would be covered by the Foundation's policies, as enacted by the Board or under its authority. I don't think that would be in scope for a policy about RFCs within the community. Harej (talk) 23:39, 26 January 2024 (UTC)
- That's kind of precisely my point. The proposal doesn't mention that at all, but I think it is relevant to the concept of post-action ratification RfCs. I guess I was also wondering why this might be needed since emergency actions might actually fall under the purview of the Board rather than functionaries. I can't decide if this proposal is complicating things, obfuscating them, or just adding a policy that will be overridden by legalities or board actions. – Jph2 (talk) 00:40, 27 January 2024 (UTC)
- I don't think it's necessarily the case that emergency actions would automatically be a Board matter. The Miraheze community, independently of the nonprofit overseeing it, has its own policies for content and conduct, its own volunteers for enforcing these policies, and internal processes, including processes to discuss changes to policies. To use the example of Requests for Comment/IRC that inspired this proposal, the community handled the entire matter from beginning to end without the involvement of Miraheze Limited. So the community appears to have the capacity to handle these sorts of issues, at least many of them, and how the community handles those situations should be up to the community to decide. My proposal is an idea I had to represent the precedent of the IRC RFC in writing.
- Now, say something urgent came up, and for whatever reason, it could only be addressed through official action of the WikiTide Foundation. Organizations ideally come up with policies ahead of time to deal with these sort of contingencies. Foundation policies are published on-wiki as we approve them. If such an emergency came up, it required official Foundation intervention, and policy did not provide explicit guidance, what would likely happen is that we would meet as a Board and then determine what action would need to be taken. Since time would be of the essence, we would only take the action that was necessary to resolve the issue and not go beyond that. We would then share with the community whatever we are able to share.
- So I would say this proposal is meant to serve as the default procedure in situations where functionaries need to take extraordinary action beyond what the community's policies allows, in the situations where the community can intervene, and the community has shown before it can handle an urgent, time-sensitive situation. And since the community is in charge of its day-to-day administration, it would be the procedure used in most of those cases. I'm not sure where the gotcha is if the Board would do something very similar, assuming it has not already proactively declared how it would handle a certain situation. Harej (talk) 00:42, 29 January 2024 (UTC)
- That's kind of precisely my point. The proposal doesn't mention that at all, but I think it is relevant to the concept of post-action ratification RfCs. I guess I was also wondering why this might be needed since emergency actions might actually fall under the purview of the Board rather than functionaries. I can't decide if this proposal is complicating things, obfuscating them, or just adding a policy that will be overridden by legalities or board actions. – Jph2 (talk) 00:40, 27 January 2024 (UTC)
- Anything involving the WikiTide Foundation would be covered by the Foundation's policies, as enacted by the Board or under its authority. I don't think that would be in scope for a policy about RFCs within the community. Harej (talk) 23:39, 26 January 2024 (UTC)
Proposal 7: Determining Consensus[edit | edit source]
By default, no minimum threshold or support ratio exists for Requests for Comments. Stewards will use their discretion to decide whether consensus has been reached on a proposal.
In certain situations, like the Reorganization of Miraheze, it may make sense to specify that the outcome will be determined explicitly on the allocation of votes. The number of winners, and threshold for winning, shall be stated upfront before the start of voting. While the proposer can recommend the voting system to be used, the use of this system shall be confirmed by a Steward prior to the start of voting. These criteria cannot be changed mid-vote, as this would be gaming the process to try to alter the outcome.
Rationale: Adds language to deal with situations like the aforementioned Reorganization of Miraheze RFC which did not go by the regular rules. Harej (talk) 01:37, 26 January 2024 (UTC)
Support[edit | edit source]
- Support This seems like a good refinement in the policy. – Jph2 (talk) 22:50, 26 January 2024 (UTC)
- Support Commetian Empire (talk°•◇•°CentralAuth) 00:45, 27 January 2024 (UTC)
- Support Useful. Redmin Contributions CentralAuth (talk) 17:15, 28 January 2024 (UTC)
- Strong support Obviously. BrandonWM (talk • contributions • global • rights) 01:22, 30 January 2024 (UTC)
- Strongest support This should have been in place already. Defining consensus should be predefined, immutable during voting, and not open to interpretation. Kourouklides (talk) 07:21, 2 February 2024 (UTC)
Abstain[edit | edit source]
Oppose[edit | edit source]
- Oppose In my view allowing the proposer to determine or even recommend the system of voting is not sensible. The same voting standards should be followed for all Requests for Comments that concern policy modifications or additions. The Reorganization request is given as an example of this went well but that was a "special" request which did not concern new policies. I would be able to accept an exception for special requests like the one mentioned but I would not accept the proposer being the one who is able to impose a voting system based on their personal preferences which would have the potential to give their proposal an unfair advantage compared to proposals that use the common system. --DeeM28 (talk) 11:59, 31 January 2024 (UTC)
- Weak oppose codifying a right to an alternative voting system (even with a Steward pre-approval cause) without clarifying that an exceptional circumstance and good reason would be required opens up avenues for abuse. I'm not opposed to this as an informal best practice when the situation merits it (e.g. the merger RfC that was going to be complicated/heated but was also extremely necessary to figure out.) but if we're going to codify it we need to get the language exact to prevent abuse. --NotAracham (talk • contribs • global)
- Oppose similar to above: the sentiment makes sense, the implementation is problematic. At the very least it should be subject to a required sanity review by the Steward team. More thought should be given to examples of reasonable alternate systems as well so if it ever is invoked, it can make as much upfront sense as possible. ----raidarr ( 💬 ) 22:56, 19 February 2024 (UTC)
- Oppose same as above, possibly a good idea in theory though but needs more fine tuning Collei (talk) (contribs) 20:36, 24 February 2024 (UTC)
Comments[edit | edit source]
- The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.