Requests for comment/Reforming the RFC process

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
Dialog-information on.svgThis is a subpage; for more information, see the Requests for comments page.


The goal of this page is to set some base-level expectations as to how a Meta RFC should operate. Credit on some of these proposals is due to User:Snowolf/RfC.

Starting a RFC

Base assumptions: An improper RFC is invalid, and may be closed if the requirements are not met after a reasonable period of time. This only applies to RFCs opened after (any of) these proposals are enacted. Nothing in this section is intended to supersede the global bans process.

Proposal 1: For the initiator of the RFC

At the time of starting the RFC, the proposer must:

  1. have a Wikimedia account; and
  2. be registered for more than three months before making the request; and
  3. have at least 250 edits globally (on all Wikimedia wikis).

Discussion for proposal 1: For the initiator of the RFC

  • Support Support As far as a rationale for this entire RFC: right now Meta RFC acts like a complete free-for-all and anything goes, and really doesn't accomplish much. I am setting out a few proposals that are designed to bring some order out of the chaos. As far as this specific proposal: this prevents IPs and very new accounts (sometimes long-term abusers) from either a) bringing slanderous accusations to Meta, or b) presenting bizarre ideas that don't have a lot of grounding (and often misunderstand what Wikimedia does). For reference, this is half the requirements of what is required to start a global ban. --Rschen7754 21:03, 14 June 2020 (UTC)
  • Support Support · This make sense. -- CptViraj (talk) 06:46, 15 June 2020 (UTC)
  • Support as minimum requirement, not against more strict requirements either. Stryn (talk) 15:46, 15 June 2020 (UTC)
  • * Comment. I wonder whether on wikis with extensive abuse, people stick around to do 250 edits, or are instead blocked long before that or leave on their own due to the abuse. This may leave very few dissenting voices to initiate an RfC. So perhaps lower edit bar might be set, or exceptions should be allowed via requests on RfC talk page Thhhommmasss (talk) 18:35, 16 June 2020 (UTC)
    • This is global, so they could go and edit another Wikimedia wiki. --Rschen7754 19:05, 16 June 2020 (UTC)
  • Oppose Meh. This restriction doesn't seem to be related to a visible problem. I looked at the 10 most recent RFCs in the open list. Only out of the 10 would be prevented by this rule (and that one, started by a logged-out editor, is a complaint that needs to be redirected to a more suitable forum regardless of how many edits the user might have). WhatamIdoing (talk) 22:30, 16 June 2020 (UTC)
    @WhatamIdoing: I would like to note that the issues with the RFCs are not just logged-out people, but also include issues with procedure and subject matter, hence the other proposals. ミラP 23:54, 17 June 2020 (UTC)
    I don't think that this proposal is necessary to address problems with procedure and subject matter. I'm not sure that it would even be very helpful for addressing those other problems. People with thousands of edits make bad proposals and start inappropriate RFCs all the time, and people with fewer than 250 edits start good RFCs. If the problem is inappropriate content, then some sort of review process (which the English Wikipedia is considering) or requiring multiple editors to endorse the RFC (as the German Wikipedia has done for years) would be more pointful. Also: you've edited at the Japanese Wikipedia. It has a higher percentage of IP/logged-out editors than anywhere else. This rule would not affect all of the online communities equally. WhatamIdoing (talk) 18:05, 18 June 2020 (UTC)
  • Support Support per Rschen7754's comments. Meeting these requirements shows that you are experienced enough to be trusted by the Wikimedia community. Allowing everyone to start RFCs without checking them for experience causes a lot of pointless RFCs that waste a lot of people's time that they could have spent on serious RFCs. I second Stryn on any possibility of strictening these requirements. ミラP 23:41, 17 June 2020 (UTC)
  • Oppose Oppose: Someone that has not registered yet may be experienced enough, he should not be forced to wait for 3 months just to be able to launch an RFC about a problem. --Ruhubelent (talk) 07:04, 18 June 2020 (UTC)
  • Support Support assuming 2 reads "registered their account at any of the projects", no "having an account on Meta for three months".--Ymblanter (talk) 10:17, 20 June 2020 (UTC)
  • Oppose Oppose: It's not true to think that a user with less than 3 months of registration cannot be helpful. Time of registration does not correlate with time spent on the wiki. You could have a 2010 account and have made a few edits each year, or have a 2 month account and have spent 10 hours a day using Wikimedia sites each day for 2 months. Overall, I don't think there should be any requirements on starting an RfC. All edits aren't the same either. If you're starting an RfC, you have a problem and would like to put forth a solution to the community. I oppose any requirements to stop a user from creating an RfC. It's already a pretty big barrier to make a Meta RfC: most users who lack the appropriate interest/knowledge (which I believe is what this requirement is intended to prevent) won't be creating Meta RfCs anyway. ProcrastinatingReader (talk) 10:59, 20 June 2020 (UTC)
  • Oppose Oppose: Reduce to 1 month + 100 edits simply to limit socking, and I might agree. –SJ talk  23:14, 20 June 2020 (UTC)
  • Support Support --Novak Watchmen (talk) 15:36, 22 June 2020 (UTC)
  • Support Support per Rschen7754. —MarcoAurelio (talk) 09:37, 24 June 2020 (UTC)
  • Support Support. Sgd. —Hasley 15:12, 25 June 2020 (UTC)
  • Support Support If a user that hasn't been on the project has an urgent and serious problem that can't wait three months, the worst case scenario is that they ask an experienced user to file an rfc for them. Zoozaz1 (talk) 14:38, 28 June 2020 (UTC)
  • BA candidate.svg Weak oppose This does not appear to a large enough issue, per WhatamIdoing above. There are probably unregistered users who are knowledgeable enough to start a good RFC about a problem, and equally many users that meet the criteria set out above who are not. I think it best to use other methods to address the concerns laid out by Rschen7754, however given the ability to ask for assistance from others, it shouldn't be too much of an issue, if implemented, for those affected. 𝒬𝔔 22:34, 28 June 2020 (UTC)
  • BA candidate.svg Weak oppose Wie WhatamIdoing und Quantocius Quantotius. Das ist zwar eine Lösung auf der Suche des Problems, aber eine Umsetzung würde auch nicht viel ändern, weil die Bedingungen sehr einfach zu bekommen sind. Grüße vom Sänger ♫(Reden) 05:18, 2 July 2020 (UTC)
  • BA candidate.svg Weak oppose per WhatamIdoing. The proposed standards are not unreasonable, but it doesn't seem like there's really much to be gained to justify the nuisance costs. Enforcement would require digging through the users' stats to check for compliance, at some point it will get in the way of someone it shouldn't, and this seems like a good opportunity to preemptively prune low value rule creep. 06:12, 7 July 2020 (UTC) —The preceding unsigned comment was added by Alsee (talk)

Support Support. Pushes those that do not meet the criteria to try to solve the issue locally. Users who have started editing recently usually do not know immediatly what meta is.--Snaevar (talk) 22:54, 7 July 2020 (UTC)

Proposal 2: Required notification of party

If the RFC concerns one party or a few parties, the initiator of the RFC must notify them on their talk page: either on the wiki in question or on Meta.

Discussion for proposal 2: Required notification of party

  • Support Support because right now people can literally go months without being notified that serious accusations are being made against them on Meta RFC. --Rschen7754 21:06, 14 June 2020 (UTC)
  • Support, makes sense. Stryn (talk) 15:47, 15 June 2020 (UTC)
  • Support Support per Rschen7754 and Stryn. ミラP 23:41, 17 June 2020 (UTC)
  • Support Support · Of course. -- CptViraj (talk) 04:28, 18 June 2020 (UTC)
  • Support Support, do not see any pitfalls with this part.--Ymblanter (talk) 10:18, 20 June 2020 (UTC)
  • Support Support --Novak Watchmen (talk) 15:37, 22 June 2020 (UTC)
  • Support Support. Due process. —MarcoAurelio (talk) 09:38, 24 June 2020 (UTC)
  • Support Support. Sgd. —Hasley 15:12, 25 June 2020 (UTC)
  • Support Support Zoozaz1 (talk) 14:46, 28 June 2020 (UTC)
  • Support Support This more or less should go without saying. 𝒬𝔔 22:35, 28 June 2020 (UTC)
  • Support Support Das sollte eine Selbstverständlichkeit sein. Grüße vom Sänger ♫(Reden) 05:22, 2 July 2020 (UTC)

Support Support. Makes it less likely that discussions get one-sided, plus obviously people have the right to stand up for themselves.--Snaevar (talk) 22:54, 7 July 2020 (UTC)

Proposal 3: Required notification of wiki

If the RFC concerns the conduct of several users on the same wiki, or the conduct of an entire community of a Wikimedia wiki, the initiator of the RFC must post a neutrally-worded notice linking to the RFC on a prominent page on that wiki, such as the village pump (links). If the initiator is unable to do so because they are blocked on that wiki, they must post a notice on the steward noticeboard requesting assistance.

Discussion for proposal 3: Required notification of wiki

  • Support Support for the same reasons as above. --Rschen7754 21:07, 14 June 2020 (UTC)
  • Support Support, with proviso that any Admins who delete such notices or retaliate against the posters of said notice (as happened on Croatian wiki) are immediately removed as Admins and banned from WP Thhhommmasss (talk) 18:40, 16 June 2020 (UTC)
    • I thought about this but since it's more controversial and might be considered a global policy I decided to hold off on proposing and wait for another round. --Rschen7754 05:32, 18 June 2020 (UTC)
  • Support Support per Rschen7754. ミラP 23:41, 17 June 2020 (UTC)
  • Support Support, do not see issues. What about RfCs which concern WMF?--Ymblanter (talk) 10:22, 20 June 2020 (UTC)
  • Support Support --Novak Watchmen (talk) 15:37, 22 June 2020 (UTC)
  • Support Support as above. —MarcoAurelio (talk) 09:39, 24 June 2020 (UTC)
  • Support Support obviously. Sgd. —Hasley 15:07, 25 June 2020 (UTC)
  • Support Support Zoozaz1 (talk) 14:46, 28 June 2020 (UTC)
  • Support Support As with proposal 2. 𝒬𝔔 22:36, 28 June 2020 (UTC)
  • Support Support Wie bei Nummer 2, das sollte selbstverfreilich sein. Grüße vom Sänger ♫(Reden) 05:32, 2 July 2020 (UTC)
  • Support Support.--Snaevar (talk) 22:54, 7 July 2020 (UTC)

Proposal 4: Global policies

Major changes to global policies require a neutrally-worded notification to be sent to Distribution list/Global message delivery.

Discussion for proposal 4: Global policies

  • Support Support If a wiki is going to be subject to a global policy, they should be invited to comment in the relevant discussion. I said "major" to avoid spamming 900+ wikis for minor noncontroversial changes. --Rschen7754 21:07, 14 June 2020 (UTC)
  • Support for now, but in long term I wish we can use the notifications for global policies instead of spamming village pumps, but it's not relevant in this RfC. Stryn (talk) 15:51, 15 June 2020 (UTC)
  • I'm not sure about this. I can imagine things that could be reasonably understood as "major changes" to what are technically global policies, which still don't impact most users, and wouldn't really need so much attention. For example, changes to the New wikis importers policy wouldn't be of interest to most users, and using the global distribution list seems like overkill. --Yair rand (talk) 19:25, 15 June 2020 (UTC)
  • Oppose Maybe not yet I like the concept, but this needs a little more thought. Making this workable would require a definition of "major" and "global policy". Also, receiving messages really becomes a burden on the smallest wikis. See phab:T130602 for some more information. It might make more sense to create a smaller list (e.g., the top 25 wikis by number of active editors) instead of spamming wikis with very few editors. Also, there's nothing in here about translation. Meta-Wiki is theoretically a multi-lingual site, and theoretically someone could fulfill this requirement by delivering a message in a language that 99% of the recipients don't read. WhatamIdoing (talk) 22:39, 16 June 2020 (UTC)
  • Oppose Oppose for now, without prejudice to a delayed roll-out after issues like village pump spamming, translation, and defining "major" and "global policy" being addressed. ミラP 23:41, 17 June 2020 (UTC)
  • Leaning oppose, we are already getting 2 much information via various global channels, and this delivery channel is becoming inefficient.--Ymblanter (talk) 10:24, 20 June 2020 (UTC)
  • Leaning oppose. –SJ talk  23:14, 20 June 2020 (UTC)
  • Maybe this whole problem could be discussed in a separate discussion about the "policy of global policies". --MF-W 00:33, 21 June 2020 (UTC)
  • Support Support --Novak Watchmen (talk) 15:38, 22 June 2020 (UTC)
  • BA candidate.svg Not yet Largely per WhatamIdoing and Ymblanter. I would support if those issues can be worked through, but I think it would be better to address this in seperate discussion. 𝒬𝔔 22:38, 28 June 2020 (UTC)

Proposal 5: Deletion

Meta administrators may not only close invalid RFCs but may delete them at their discretion.

Discussion for proposal 5: Deletion

  • Support Support because unsubstantiated accusations should not be left on Meta in perpetuity. --Rschen7754 21:08, 14 June 2020 (UTC)
  • Support, we can always remove attacks or nonsense requests, even without this RfC. Stryn (talk) 15:56, 15 June 2020 (UTC)
  • Support Support I also think that "courtesy blanking" should be listed as an option. WhatamIdoing (talk) 22:41, 16 June 2020 (UTC)
  • Oppose: Very vulnerable towards abuse as there is no any standard regulation on what conditions an RFC would be considered invalid. An admin may just close an RFC to protect another admin... There has been double standards of this case, my RFC related to Turkish wiki was closed on the day Wikipedia was unblocked in Turkey, the admin that closed it stated "it is unedited for 6 months." but at the same time RFCs not edited for 14 months were left open. --Ruhubelent (talk) 18:42, 17 June 2020 (UTC)
    • Proposals 1-4 are what defines if RFCs are valid. --Rschen7754 01:38, 18 June 2020 (UTC)
So, what you mean here is an admin may close an RFC if; 1) that was created without a registered account or by someone younger than 3 months or by someone with less than 250 edit? 2)the related parties are not notified? --Ruhubelent (talk) 07:02, 18 June 2020 (UTC)
  • Support Support provided "courtesy blanking" and even policy-sanctioned suppression of prior edits before courtesy blanking are listed as options. ミラP 23:41, 17 June 2020 (UTC)
  • Oppose Oppose: There is no "invalid" RFC as there are no standard rules to assess whether an RFC page is invalid or not, first that has to be established. Otherwise, an admin may just delete an RFC arbitrarily, asserting it is invalid. --Ruhubelent (talk) 06:56, 18 June 2020 (UTC)
  • Oppose Oppose We need to have a general deletion policy, and there is no need to have a special provision here.--Ymblanter (talk) 10:26, 20 June 2020 (UTC)
  • Oppose Oppose per Ruhubelent. ProcrastinatingReader (talk) 11:01, 20 June 2020 (UTC)
  • Agreed; invalid or ill-formatted RFCs shouldn't lie around forever. --MF-W 00:34, 21 June 2020 (UTC)
  • Support Support --Novak Watchmen (talk) 15:39, 22 June 2020 (UTC)
  • Support Support, although vandalism and attack pages are already covered by WM:CSD#G1 and WM:CSD#G9. —MarcoAurelio (talk) 09:43, 24 June 2020 (UTC)
  • Support Support, per MA. Sgd. —Hasley 15:08, 25 June 2020 (UTC)
  • Oppose Oppose The CSD already cover the cases where this is needed (esp G criteria 1, 3, 7, and 9). In the absence of specific evidence showing that there are RFCs that don't meet any existing criteria that also need rapid deletion I see no harm in having a proper deletion discussion, although this could be revisited if volume becomes a problem, and pages could still be courtesy blanked while the discussion is ongoing if need be. Even if this route is selected I would prefer wording for the new CSD to be clearer than merely "invalid RFC". 𝒬𝔔 22:41, 28 June 2020 (UTC)
  • Oppose Oppose. Meta´s deletion policy covers the worst cases. Closing is fine, but deleting them is a bit much.--Snaevar (talk) 22:54, 7 July 2020 (UTC)

During the RFC

Proposal 6: Patrolling

Meta administrators or stewards can either collapse or move to the talk page discussion(s) that are unproductive (i.e. unconstructive, uncollaborative, ad hominem/personal attacks, unsubstantiated accusations, off-topic).

Discussion for proposal 6: Patrolling

  • Support Support because right now you can say anything you want at RFC, sometimes even making personal attacks, and nobody does anything about it. This should improve the usefulness of discussion and actually get things decided and consensuses formed. --Rschen7754 21:13, 14 June 2020 (UTC)
  • Support Support This is very important, since some RfCs have become unwieldy due to all the nonsense. I thought reverting such comments might work, but perhaps collapsing or moving them to talk page is better Thhhommmasss (talk) 18:46, 16 June 2020 (UTC)
  • Support Support Also global sysops. WhatamIdoing (talk) 22:45, 16 June 2020 (UTC)
  • Oppose Oppose: Terms like "unproductive/unconstructive" are vague and subjective. It is not something standard or objective, an admin may just close an RFC page that is against his biased view, asserting it is "unproductive/unconstructive". It is open to abuse. --Ruhubelent (talk) 18:48, 17 June 2020 (UTC)
  • Support Support, preferably if global sysops are allowed to do so. ミラP 23:41, 17 June 2020 (UTC)
  • Leaning suport, but I would be very careful with this - if a broad circle of users are allowed to patrol RfC they might be overdoing it, as their standards would not be aligned.--Ymblanter (talk) 10:43, 20 June 2020 (UTC)
  • Support SupportSJ talk  23:14, 20 June 2020 (UTC)
  • Support Support --Novak Watchmen (talk) 15:40, 22 June 2020 (UTC)
  • Support Support. —MarcoAurelio (talk) 09:44, 24 June 2020 (UTC)
  • Support Support Sgd. —Hasley 15:08, 25 June 2020 (UTC)
  • Support Support Zoozaz1 (talk) 14:46, 28 June 2020 (UTC)
  • Support Support Noting that per the Civility policy all users are already empowered to remove highly uncivil or insulting comments. It should also be acceptable for experienced users to collapse off-topic or unconstructive sections. I do think that Ruhubelent and Ymblanter raise valid concerns, but borderline cases can be handled on an individual basis on the talk page for the RFC where additional input can be sought if an action is challenged. 𝒬𝔔 22:42, 28 June 2020 (UTC)
  • Support Schwache Unterstützung Solange das nicht als Totschlagargument gegen sprachlich nicht so versierte missbraucht wird gerne, Meta:Civility wird imho allerdings zu leicht als Ponyhofpflicht missverstanden. Grüße vom Sänger ♫(Reden) 05:36, 2 July 2020 (UTC)
  • Support Support. Enchaurages productive comments and keeps the page organised.--Snaevar (talk) 22:54, 7 July 2020 (UTC)

Proposal 7: Banning

Meta administrators or stewards can ban a user from contributing to a RFC for repeated unproductive behavior, enforceable by blocking if necessary. Appeals can be made at RFH and determined by a consensus of Meta administrators/stewards.

Discussion for proposal 7: Banning

  • Support Support because sadly - some editors are simply not capable (as in, not willing) to contribute productively to constructive and collaborative discussions. --Rschen7754 21:14, 14 June 2020 (UTC)
  • Support Support particularly if their comments have been repeatedly collapsed/removed to talk page, yet they continue with unproductive behavior. Also single outrageous behavior instance should qualify for banning (e.g. if on CW RfC it could be found out who engaged in hate speech, writing "Kill Croats", such person should be immediately life-time-banned not only from the RfC process, but from entire WP). In general, anyone who engages in attacks on an ethnic, racial, religious, sex, or sexual-orientation basis, should be placed on a fast-track for banning. Thhhommmasss (talk) 19:46, 16 June 2020 (UTC)
  • Support Support Also global sysops. The place for an appeal should be specified. Presumably Meta:Requests for help from a sysop or bureaucrat is the right page. WhatamIdoing (talk) 22:45, 16 June 2020 (UTC)
    • Global sysops do not have jurisdiction over Meta, they are not allowed to use the toolset to enforce the ban. So only Meta admins and Stewards can properly issue any sanction that is enforceable. — regards, Revi 08:50, 17 June 2020 (UTC)
  • STRONGLY OPPOSE. Absolutely open to abuse. Terms like "unproductive/unconstructive" are vague and subjective. It is not something standard or objective, an admin may just close an RFC page that is against his biased view, asserting it is "unproductive/unconstructive". It is open to abuse. --Ruhubelent (talk) 18:51, 17 June 2020 (UTC)
  • Support Support, preferably if global sysops are allowed to participate in the consensus process of determining whether to ban. ミラP 23:41, 17 June 2020 (UTC)
  • Support Support, partial blocks are already available--Ymblanter (talk) 10:47, 20 June 2020 (UTC)
  • Support Support, clarifies something already possible. –SJ talk  23:14, 20 June 2020 (UTC)
  • Support Support --Novak Watchmen (talk) 15:40, 22 June 2020 (UTC)
  • Support Support. —MarcoAurelio (talk) 09:46, 24 June 2020 (UTC)
  • Support Support. Sgd. —Hasley 15:09, 25 June 2020 (UTC)
  • Support Support Again noting that Civility already provides them wide latitude in sanctioning users for failure to comply. Users that fail to respond to admonishments should be partially blocked from the page for the duration of the RFC, or in the case of gross-violations of the civility policy just be longterm/unlimited blocked sitewide. 𝒬𝔔 22:44, 28 June 2020 (UTC)
  • Strongly Oppose Oppose:Terms like "unproductive/unconstructive" are vague and subjective. It is not something standard or objective, an admin may just prevent someone that is against his biased view, asserting he/she is "unproductive/unconstructive". It is open to abuse. It is way of preventing free speech (which does not exist on Wiki anyway) completely, even on theoretical levels. --Ruhubelent (talk) 14:06, 29 June 2020 (UTC)
  • Oppose Oppose. There should be an discussion on banning on meta in general before this happens.--Snaevar (talk) 22:54, 7 July 2020 (UTC)

Closing

Proposal 8: Closing

Only Meta administrators or stewards can close RFCs. Only stewards can close any RFC requiring steward action or changing global policy.

Discussion for proposal 8: Closing

  • Support Support for two reasons: 1) in the past some users outside these categories have mass-closed RFCs that should not have been closed, which caused some chaos and lack of progress in resolving some matters, or led to premature conclusions. 2) If these are the only groups that can close these RFCs then perhaps they will take ownership of the responsibility and keep the RFC process running - otherwise everybody's problem is nobody's problem. And FWIW I am not currently a Meta administrator or steward. --Rschen7754 21:05, 14 June 2020 (UTC)
  • Q: To clarify - [1] "Meta Admins can close the RFC involving S actions, but S should (preferably) do it" or [2] "Meta Admins cannot close RFCs involving S actions and S must do that" - which one is true? — regards, Revi 05:47, 15 June 2020 (UTC)
    • I mean the second - but the first could be a valid proposal. --Rschen7754 05:52, 15 June 2020 (UTC)
      • I edited the proposal to reflect this. --MF-W 00:36, 21 June 2020 (UTC)
  • Oppose Oppose For RFC pages that looks like purely spam, or did not created seriously (e.g. global ban requests that do not fullfill the policy), closure of them by any users should still be allowed. --Liuxinyu970226 (talk) 03:22, 17 June 2020 (UTC)
  • I am fine with the either interpretation of my Q, but since Rschen says [2] was what he meant, I am fine with that. — regards, Revi 08:52, 17 June 2020 (UTC)
  • OPPOSE: Closing/terminating/aborting an RGC should not be up to the personal views/verdicts/conclusion of individuals, there should be standard rules for closure and admins must be closing RFC pages only in accordance with those standard rules. First, such rules have to be established and then admins must be executing those "legislatures'. Otherwise, as pointed in my previous oppose votes regarding 6th and 7th proposals, this proposal is also very open to abuse. --Ruhubelent (talk) 18:57, 17 June 2020 (UTC)
  • Support Support, preferably if global sysops are allowed to do so. I'm open to the possibility of trusted users who don't fit those three groups being allowed to speedy close RFCs that don't meet criteria though. ミラP 23:41, 17 June 2020 (UTC)
  • Update: I also endorse GZWDer's idea. ミラP 17:15, 1 July 2020 (UTC)
  • Support Support --Novak Watchmen (talk) 15:41, 22 June 2020 (UTC)
  • We should also said "An RFC may be withdrawn by its creator, if there are no other users proposing or supporting a proposal different from status quo."--GZWDer (talk) 17:36, 23 June 2020 (UTC)
  • Support Support. I also support GZWDer addition regarding the withdrawal of RfCs. —MarcoAurelio (talk) 09:47, 24 June 2020 (UTC)
  • Support Support, idem GZWDer. Sgd. —Hasley 15:10, 25 June 2020 (UTC)
  • GA candidate.svg Generally Support Both parts of the proposal. However, I second (or fourth?) GZWDer's point above on self-withdrawals. Liuxinyu970226's point is also solid. There may be cases where an RFC is obviously malformed and any experienced user should be permitted to close it to reduce sysop workload, though as I mentioned earlier in many cases it will probably suffice to tag bad RFCs for CSD or nominate them for deletion as appropriate. Ruhubelent's concerns are valid but I see this as the starting point in part of a larger effort to regularize RFC procedures which should in time lead to discussions that address the points raised in opposition. 𝒬𝔔 22:49, 28 June 2020 (UTC)
  • Support Support. There needs to be an order to who closes RFCs.--Snaevar (talk) 22:54, 7 July 2020 (UTC)

Proposal 9: Closing guidance

When an RFC concerns a wiki and the collective community and/or collective admins at that wiki are credibly and seriously called into question, consensus should be evaluated primarily based on the evidence and external review by the uninvolved global community. Editors active at the subject wiki may participate and present evidence and arguments as usual.

Examples of seriously calling into question a collective community or collective admins would include:

  • A pattern of abuse by a significant proportion of admins, with the intent or effect of inappropriately filtering the population of local editors.
  • A pattern of gross disregard for any non-optional policy, including but not limited to:
    • Copyright policy.
    • Biography of Living Persons policy.
  • Any pattern grossly violating our general moment mission or the mission of that type of project.
    • For Wikipedias, this would include a pattern of gross violation of the non-optional Neutral Point of View policy.
  • Any organized infiltration that threatens to subvert a project.

Discussion for proposal 9: Consensus guidance

  • Support Support. I could cite concrete cases but the issue should be clear without it. If abusive admins are expelling ordinary and policy-supporting editors from the local population, if they are grooming a population of allied ideological warriors, they shouldn't be able to filibuster external review simply because they were successful. Votes from the surviving pool of local editors just brings corrupt opposes who like being beneficiaries of corrupt administration. A few corrupt opposes from abusive admins themselves can make a strong Global Community Consensus look weak, and a stack of corrupt canvassed opposes can make it difficult to avoid a "no consensus" result even if the Global Community review were to unanimously find the wiki is corrupt.
    It's easy to say consensus isn't a headcount, but it's a lot easier for a closer when there's existing text telling them - and telling RFC participants - that heads from the subject wiki don't get counted up an any actual or theoretical headcount. Alsee (talk) 17:36, 6 July 2020 (UTC)
  • I thought about proposals like this but ultimately decided to not make them this round and focus on noncontroversial proposals. But now that it's been made: I would prefer a more general statement similar to that used on SRGP like "Stewards will likely give weight to the opinions of those not involved in the incidents in question or those who have been canvassed for support" - because I don't know that we completely want to discount all the opinions of those from that wiki (including those who were indeed blocked on that wiki for improper reasons). --Rschen7754 18:47, 6 July 2020 (UTC)
    Rschen7754 I agree that consensus isn't a list of absolutes or "musts" or "can'ts". I'm an experienced closer on EnWiki, and EnWiki has pages of useful closing advice. It lists factors to consider, principals, and various non-absolute "shoulds". In part it gives closers guidance on how the community wants things to be closed. In part it gives closers something to point to and say "I closed it this way because this says it should be closed this way". Regarding your concerns, I'd like to draw attention to my phrasing were I used the word "should" and the phrase "primarily based on". I hope(?) it is clear that that does not require anything like completely discounting all opinions from the wiki. I dislike the approach you suggested - and I hope you won't be offended if I explain my dislike by casting it in the worst possible light. It talks solely to participants, it basically says that closers can do anything they like and result is "right" only because the closer outranks you and they assert it is right. I am looking to talk to closers, for the community to say we are concerned that votes from subject-wikis may be unreliable, to say we want them to consider that subject-wiki-votes may not be an accurate reflection of the global community will, to say that uninvolved-votes represent a sampling of a vastly larger global community even if they are merely 50% of the votes in the RFC, that we do want a global community consensus to be able to override and fix a corrupt local consensus, and I want closers to be able to say their close is correct because [[linky]] says it was supposed to be closed that way. Alsee (talk) 13:51, 7 July 2020 (UTC)
  • Without regard for the merit of this proposal, I think it's better not to add more proposals in this RFC, especially when it already was running for three weeks. As a general note, I think RFCs are better if a whole policy text is discussed and adjusted according to the discussion, instead of voting on single sentences. But if this style is already chosen, it can quickly get confusing if more proposals keep being added. --MF-W 23:00, 6 July 2020 (UTC)
  • Support Support. Pretty much spot on.--Snaevar (talk) 22:54, 7 July 2020 (UTC)

General comments

  • I think a global ArbCom, mentioned by some, many be a better solution for dealing with abuse on smaller wikis which do not have the capability to police themselves, since bringing such wikis back into compliance with WP principles requires longer-term, fast-responsive oversight. The RfC process may be better suited to broader policy issues (e.g. should a global ArbCom be established), while the more detailed dispute management and continuous oversight of smaller wikis might be better administered by such a global ArbCom Thhhommmasss (talk) 18:59, 16 June 2020 (UTC)
    • Well, I feel like the enforcers of the so called "Universal Code of Conduct" will be the de facto Global ArbCom... — regards, Revi 08:48, 17 June 2020 (UTC)
UCC seems geared toward harassment. While there’s been harassment, even hate speech in CW RfC, calling for killing entire ethnic groups, the problem goes beyond that to POV-pushing, e.g. openly-proclaimed nationalistic agendas, with systematic violation of core WP principles like NPOV and Reliable Sources (e.g. CW Admins proclaiming Holocaust-denying convicted fraudsters have the “only truth”, while Holocaust Museums and western/Croat historians publish “lies and fabrications”), plus reverting/blocking editors who do not fit that POV-agenda, even openly boasting, as in CW RfC, with diffs provided, that they’ve blocked people for daring cite Croat and international linguists, because this goes against their extremist nationalist agenda
Thus even if they were to promote their Holocaust-denial and other massive lies on WP servers in a non-overtly harassing fashion, this would not solve the problem. What’s needed is a body or process that is willing to enforce core WP principles, like NPOV and Reliable Sources, as if they actually mattered, instead of allowing them to be grossly violated, for now over a decade on CW, with very harmful social consequences as Croat and other historians state. Even if WP has zero interest in acting in socially-responsible manner (i.e. not allowing use of its servers to promote hateful ideologies that lead to mass slaughter of women and children, a specialty of Balkan-nationalists), then at least there should be interest in enforcing WP principles
Suggestions to improve the efficiency of current process, as is focus here, will also not solve the problem if there’s a core unwillingness to take action to enforce WP principles. Instead this will just lead to faster non-action, with continuing Holocaust-denial and other massive lies promoted via WP servers, with WP’s full blessing Thhhommmasss (talk) 19:30, 28 June 2020 (UTC)

Here are a couple of other items that would be very helpful:

  1. Allow only autoconfirmed users to comment on RfC, with exceptions for those who first present a valid case for inclusion on Talk page. I think only established members of the WP community should get a voice as to how WP is governed, not random parachutists and vandals (in CW RfC non-autoconfirmed users repeatedly vandalized page to disrupt RfC, plus this can lead to other abuse)
  2. Consider adding timeframe for decisions (e.g. 1 month), after discussion is closed. Since we have no insight how decisions are made, not sure why CW RFC has still not been decided, now going on 6 months after initial requests for close. If decision requires more than target timeframe, then decision-makers could post notice of extension (e.g. for 1 more month)
  3. Consider public deliberation of RfCs, similar to community town hall meetings, where stewards or Meta Admins publicly discuss issue and come up with decision. This could be done after public discussion is closed, in separate section of same RfC page, and should not require any additional effort, since such discussion no doubt already takes place. This would publicly reaffirm and help everyone understand core WP principles and processes, while providing greater decision-making transparency Thhhommmasss (talk) 21:44, 16 June 2020 (UTC)
I don't think that bad behavior on a single page should result in new accounts being refused at all RFCs. It would make more sense to semi-protect the single RFC than to reject everyone else. Being autoconfirmed is a per-wiki state, and there are many respected editors throughout the movement who have never had a reason to make any edits here at Meta-Wiki. We should not ban all those editors just because one RFC was getting vandalized. WhatamIdoing (talk) 22:50, 16 June 2020 (UTC)
Yes I agree, the way it should work is to check if people are autoconfirmed on any wiki, for them to be able to comment on RfCs. And unless a good reason is given for an exception, they should be registered, i.e. no comments from IP addresses (all CW RfC vandalizations came from IP addresses) Thhhommmasss (talk) 23:47, 16 June 2020 (UTC)
I do not think that this is possible on a technical level (i.e. we would need an actual global autoconfirmed group). Otherwise Meta admins would have to check every editor by hand. --Rschen7754 00:32, 17 June 2020 (UTC)
I assume it ‘s easy to block just IP edits on RfC pages (while allowing them on Talk pages), which would've taken care of most CW RfC vandalizations. But there were also quite a few registered nowiki folks posting on CW RfC, which in my view shouldn’t be the case (except for requested valid exceptions). Users registered on one wiki can edit all, so there is global edit right. Don't know how complicated it'd be to add global autoconfirmed list, or do an on-the-fly cross-wiki autoconfirmed check when they click Edit on RfC page (not many people post to RfC pages, so shouldn't be resource-intensive). Engineering folks would know this much better, if that's something that's agreed upon Thhhommmasss (talk) 01:19, 17 June 2020 (UTC)
I oppose per Rschen7754, without prejudice to the idea being revisited if an RFC on a globally confirmed group passes with enough support. However, there may be rare occasions where an RFC must be protected due to (for example but not limited to) off-wiki canvassing. For the time being, another idea would be to require users to log-in to comment on RFC and enforce it with a local abuse filter similar to the one used with steward elections. ミラP 00:05, 18 June 2020 (UTC)
Requiring login would be at least step in right direction since extensive CW RfC vandalization came from IP addresses. However, I believe there was also extensive canvassing and sockpuppeting on same. Allowing non-autoconfirmed users only facilitates such RfC abuse, not to mention that users with zero active wiki participation should not have a say on wiki policies Thhhommmasss (talk) 17:23, 18 June 2020 (UTC)
The standard for auto-confirmed varies by wiki. It's four days + 10 edits at the English Wikipedia, but not at every wiki. The last time I looked up the list (which was a few years ago), there was at least one small wiki where auto-confirmed required zero days and zero edits. Therefore "autoconfirmed here if they're autoconfirmed anywhere" == "logged in".
Auto-confirmed checks are always done on the fly. However, the "on-the-fly cross-wiki autoconfirmed check" is far more technically complicated than it sounds like. We're not going to get that any time soon. WhatamIdoing (talk) 18:14, 18 June 2020 (UTC)
Everything has its cost – cost of current system is facilitation of extensive abuse, plus wasting everyone’s time reading zero-substance, hagiographic posts in support of whoever is canvassing and/or sockpuppeting. People even wasted time responding to these zero-fact posts, vainly trying to get them to say something substantive, thus creating lots of unnecessary clutter on CW RfC, further complicating RFC closing Thhhommmasss (talk) 18:36, 18 June 2020 (UTC)
  • I strongly recommend a list of things that should not be done at Meta-sanctioned RFCs, particularly one similar to this and called "What RFC is not", and also a list of Wikis that stewards/Meta admins/global sysops determine don't require RFC attention. These would discourage people from opening all those pointless RFCs and save stewards/Meta admins/global sysops a lot of time. ミラP 23:41, 17 June 2020 (UTC)
    • I think this is a good idea. --MF-W 21:47, 18 June 2020 (UTC)
      • We have to be careful with this - where do we draw the line as to what wikis can have RFCs opened against them? --Rschen7754 00:05, 19 June 2020 (UTC)
        • I see several possibilites. A solution that could easily be enforced would be something like "no RFCs "against" wikis with an arbcom / with more than X active admins/bureaucrats/CU/OS". Some things will never work, e.g., no RFCs to desysop someone on enwiki or dewiki from here will ever succeed, and that should be made clear. --MF-W 22:33, 20 June 2020 (UTC)
          • If we used ArbCom as a criteria, we would have to give the "by 25 editors" criterion that CU/OS uses since I don't think the en.wikinews ArbCom should qualify. We do have to be careful with this though: not that Meta RFC was ever an effective appeal process for issues on other wikis, but if we exclude too many wikis from here we cut off their only hope of assistance from the community and they are at the mercy of WMF. --Rschen7754 04:42, 21 June 2020 (UTC)
            • On the other hand, what's the chance of an RFC here about some enwikinews problem actually resulting in anything? --MF-W 21:52, 22 June 2020 (UTC)
  • Idea @Ymblanter: voted support on Proposal 7 stating "partial blocks are already available". Perhaps a more convenient way to enforce RFC TBans with pblocks would be to move all the RFCs (including the previous ones) into a separate custom namespace made specifically for them so that we can block them from editing all the RFCs instead of increase the number of pages a user is blocked from editing for every violation. The question is, how do we name that namespace? ミラP 01:11, 23 June 2020 (UTC)

Notifications about this RFC

Given Proposal 3: Required notification of wiki, might it make sense to advertise this RFC somewhere? --MF-W 21:48, 18 June 2020 (UTC)

@MF-Warburg: Well, we've advertised RFCs on the main page before, and this RFC will no doubt impact all of them for years if not decades to come given the clear support for most of the reform proposals, so makes sense to Support Support doing it there. Anyone else, your thoughts? ミラP 01:15, 23 June 2020 (UTC)
Sure. --Rschen7754 02:26, 23 June 2020 (UTC)

Pointlessness

  • the entire thread is pointless. Currently, admins are able to do all of the proposals proposed here - an admin is able to just close an RFC if he/she wishes no mattee r the initiatoe has 250 million edits or less than 250 edits - an admin can just close it, they are not lacking a confirmation. So, what is the point here? As for "no one being other than admins/stewards/etc being able to close", that is also the case: if I close an RFC, an admin may just revert it. --Ruhubelent (talk) 12:33, 24 June 2020 (UTC)
@Ruhubelent: Some of the votes at proposal 8 have discussed possibility of allowing anyone to withdraw their own RFCs or allowing people who don't fit in the three user groups but are experienced enough to close RFCs that fail criteria. ミラP 15:13, 25 June 2020 (UTC)
@Ruhubelent:The point in general is that we are formalizing the proccess; as of now, while some of these may be de facto in place, oftentimes there are RFCs that would do not follow these rules or would benefit from have a de jure process. Zoozaz1 (talk<nowiki>) 14:46, 28 June 2020 (UTC)
Formalising? Does someone really care about formal procedures here? I am really curious on that one. I would be very glad if a single case that followed formalities is provided. No matter whatever you formalise here, admins can do whatevee they want. No point in formalising anything here. A greater mob can dictate wikipedia as they wish and I can provide countless examples of it. One of them being my userpage being occupied by an admin due to me putting information about myself. If I talk further, they may delete this comment of mine or may even block me --Ruhubelent (talk) 22:09, 28 June 2020 (UTC)
I love your continued scaremongering and misrepresentation.  — billinghurst sDrewth 01:59, 8 July 2020 (UTC)