Wikimedia Meta-Wiki

Requests for comment/Reforming the RFC process

< Requests for comment

The following request for comments is closed. In closing this RfC, each proposal was evaluated individually based on the feedback provided by the global community and past precedent. The implemented versions exported to Requests for comment/Policy. In this closing comment, I detail and explain the results of this RFC and the reasoning for each interpretation of consensus. Starting with proposal 1, it was implemented in it's original form with majority support and some, albeit weak, opposition. It does not have many use cases, as indicated by Whatamidoing, though there is consensus for including it in the event such use cases do arise, as in general new users should not be initiating RFCs. Proposal 2 was implemented in it's original form (though I did change the colon out for a comma) with unanimous support. Proposal 3 was also implemented in it's original form without opposition. Proposal 4 was not implemented, with no prejudice against reconsideration of a more detailed proposal in the future, preferably in it's own RFC. This proposal had insufficient support and, were it implemented, the actual procedure would be quite vague. Proposal 5 was partially implemented with 68% support. The propsoal was heavily modified to conform with the comments of many on the proposal, who noted that Meta-Wiki's deletion policy covers most (if not all) potential use cases. RFCs which are harrassment, nonsense, out of scope, copyright violations, attack pages, vandalism, from a banned editor, and some others, are already covered under the deletion policy. For this reason, I have made a note under the "Closure of RFCs section" on the policy page that RFCs are not immune to criteria of the deletion policy, as it is not unthought of that such an argument may arise. This decision was a combination of reconciling the split of opinion, the lack of definition for "invalid RFCs" apart from the other proposals, and the necessity to consider how future contributors will utilize the policy page being created. If there are contributors who seek an implementation of policy more broadly about "invalid RFCs", it would be pertinent for such contributors to create a RFC with proposals on the definition of "invalid", it's distinction from the deletion criteria, and procedure for administrators. Proposal 6 was implemented with minimal opposition, and a clause for global sysops was not implemented as global sysops would be unable to enforce their actions. Proposal 7 has the same result as proposal 6: implementation with minimal opposition and without a clause for global sysops, as they would be unable to enforce it. Proposal 8 was implemented with minor opposition, including GZWDer's addition. Proposal 9 was mostly implemented with no direct opposition, and minor edits on my part for clarity. The list of examples was omitted due to the high potentiality of wikilawyering (which is common on the type of RFCs that fall under this proposal), as there are countless examples where an RFC that should fall under this proposal would not also fall under the list of examples. The phrase "credibly and seriously called into question" should be interpreted broadly, and in general the weight of involved users' comments is held to a lower degree, due to bias, than that of uninvolved editors of different projects. Best regards, and happy editing, Vermont (talk) 23:52, 13 August 2020 (UTC)[reply]

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)[reply]
  • Support Support · This make sense. -- CptViraj (talk) 06:46, 15 June 2020 (UTC)[reply]
  • Support as minimum requirement, not against more strict requirements either. Stryn (talk) 15:46, 15 June 2020 (UTC)[reply]
  • * 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)[reply]
  • 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)[reply]
    @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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose Oppose: Reduce to 1 month + 100 edits simply to limit socking, and I might agree. –SJ talk  23:14, 20 June 2020 (UTC)[reply]
  • Support Support --Novak Watchmen (talk) 15:36, 22 June 2020 (UTC)[reply]
  • Support Support per Rschen7754. —MarcoAurelio (talk) 09:37, 24 June 2020 (UTC)[reply]
  • Support Support. Sgd. —Hasley 15:12, 25 June 2020 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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. Alsee (talk) 06:12, 7 July 2020 (UTC)[reply]
  • 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)[reply]
  • Support Support. Inexperienced users should not initiate RFC.--Jusjih (talk) 04:53, 9 July 2020 (UTC)[reply]
  • Support Support. This. IPs and/or newer users might not know about the rules of Wikipedia enough (example, i bring up this wiki, English Wikipedia because of a recent experience) and may game the system because of this. SMB99thx Talk / email! 11:39, 10 July 2020 (UTC)[reply]
  • Strong support Strong support If, a RfC initiator is requesting a reform, you prevent them from doing so? ThesenatorO5-2 (talk) 09:38, 16 July 2020 (UTC)[reply]
  • Support Support--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 09:52, 18 July 2020 (UTC)[reply]

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

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

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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Leaning oppose. –SJ talk  23:14, 20 June 2020 (UTC)[reply]
  • 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)[reply]
  • Support Support --Novak Watchmen (talk) 15:38, 22 June 2020 (UTC)[reply]
  • 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)[reply]
  • Neutral Neutral This proposal need some details how it would work. SMB99thx Talk / email! 11:48, 10 July 2020 (UTC)[reply]

Proposal 5: Deletion

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

Discussion for proposal 5: Deletion

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)[reply]

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

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

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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support Support --Novak Watchmen (talk) 15:41, 22 June 2020 (UTC)[reply]
  • 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)[reply]
  • Support Support. I also support GZWDer addition regarding the withdrawal of RfCs. —MarcoAurelio (talk) 09:47, 24 June 2020 (UTC)[reply]
  • Support Support, idem GZWDer. Sgd. —Hasley 15:10, 25 June 2020 (UTC)[reply]
  •  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)[reply]
  • Support Support. There needs to be an order to who closes RFCs.--Snaevar (talk) 22:54, 7 July 2020 (UTC)[reply]
  • Support Support--Jusjih (talk) 04:57, 9 July 2020 (UTC)[reply]
  • Support Support, and also second GZWDer addition. Meta Wikimedia should follow other wikis when it comes to taking actions (English Wikipedia and Wikimedia Commons is a particular example of this as i have experienced over the years). And for the GZWDer's proposal, if i make a wrong or unsure RfC, i have a right to fix my mistake and withdraw my RfC. I have withdrawn some of many requests i made (English Wikipedia and Wikimedia Commons) because of this reason. SMB99thx Talk / email! 12:08, 10 July 2020 (UTC)[reply]
  • Strong oppose What about spam RfCs? ThesenatorO5-2 (talk)
    They must be deleted under any circumstances per proposal 5, but with admins or stewards doing so as quick as possible. I'll add my own addendum that if there is a spam RfCs, then they must be quickly closed with an admin or steward and be deleted by them. SMB99thx Talk / email! 02:57, 18 July 2020 (UTC)[reply]
    I mean that closing an obvious spam RfC is allowed by anyone who have reached 500 global edits. ThesenatorO5-2 (talk) 03:18, 18 July 2020 (UTC)[reply]

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)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
  • Support Support. Pretty much spot on.--Snaevar (talk) 22:54, 7 July 2020 (UTC)[reply]
  • Support Support. Any proposal needs discussion and audience, not rash decisions. Without it, some people might not be happy and contest the decision. This could help decreasing the incidence of disputes because of these decisions. SMB99thx Talk / email! 12:00, 10 July 2020 (UTC)[reply]
  • Support Support per Alsee. Not only will abusive, POV-pushing wikis drive away diverse editors, thus creating a biased editor base, but there is also related issue of canvassing and sockpuppeting, which further skews votes. Plus on matters of WP principles, number of votes should not matter at all, since WP principles should be like a constitution – i.e. you can’t majority vote to abolish the 1st amendment to the US constitution, just as you can’t majority-vote to abolish NPOV and RS, despite fact that many CW Admins and editors advocate and practice same. I also concur with SMB99thx that public discussion of decisions is required, with stewards publicly deliberating, just like city councils do. Without such transparency it may be difficult to gain support for decisions. In fact, let me put this more directly. Without communication from the decision-makers, in my view this process has zero-legitimacy, since it appears as just a bunch of guys (given the level of non-communication I assume its mostly guys) making arbitrary decisions, or rather non-decisions behind the scenes. As always I welcome any opposing views as to why such non-communication, which would’ve been totally unacceptable in all the private companies I worked for, is deemed acceptable on “community-based” WP Thhhommmasss (talk) 16:17, 12 July 2020 (UTC) 19:18, 10 July 2020 (UTC)[reply]
  • Support Support --Novak Watchmen (talk) 12:25, 11 July 2020 (UTC)[reply]
  • Support Support. If we ever need a discussion concerning the community of one of our wikis, it ought to be an impartial one with uninvolved editors to ensure fairness and satisfactory closure. ミラP 18:46, 18 July 2020 (UTC)[reply]
  • Support Support * Pppery * it has begun 22:49, 29 July 2020 (UTC)[reply]

Proposal 10: Unclosing

Any person who have made globally 250 edits may request reopening of any RfC that is closed as not done, and that request shall be processed by a steward or a GSysop, with the following workflow:

  • A request is filed as a RfC;
  • A community discussion is open for 3 days;
  • A steward/GSysop checks the vote, if more than 60% agrees with the reopening, it should be reopened. Although the initiator can stop the procedure.

ThesenatorO5-2 (talk) 09:53, 16 July 2020 (UTC)[reply]

Discussion for proposal 10: Unclosing

  • Support Support. In English Wikipedia there is a requests for undeletion in case if people consider it wrong or unwise decision to delete the article or there is still a demand for relist the AfD. Meta Wikimedia should have that system following the English Wikipedia. SMB99thx Talk / email! 02:52, 18 July 2020 (UTC)[reply]
  • That does not make much sense. That said, 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 14:18, 18 July 2020 (UTC)[reply]
    But what is your opinion? I will just add {{neutral}} to it. — The preceding unsigned comment was added by ThesenatorO5-2 (talk) 20. Jul. 2020, 08:47:26 (UTC)
    Please don't edit others' comments like that. I have removed the {{neutral}} template --DannyS712 (talk) 10:19, 20 July 2020 (UTC)[reply]

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)[reply]
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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
    • I think this is a good idea. --MF-W 21:47, 18 June 2020 (UTC)[reply]
      • 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)[reply]
        • 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)[reply]
          • 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)[reply]
  • 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)[reply]
  • I’d also like to contrast this process, particularly on the CW RfC, with processes I’ve experienced on enwiki. There I see Admins who are willing to enforce WP rules, make many timely decisions, involve themselves directly in disputes to manage them so they do not spin out of control, actively work to resolve them. Above all they COMMUNICATE with all participants continuously. So if the RfC process is like a SuperAdmin process where tough problems are brought to be resolved, I’m at a total loss to understand the multiple failures on the CW RfC – i.e. inability to manage the process, inability to come up with a decision, plus total inability to communicate. I do not know if this is typical of other RfCs, but given the total failure to communicate it is impossible to figure out what’s going on. In any case any process incapable of making decisions or communicating, is unacceptable and even harmful, including with respect to its own legitimacy. It therefore appears that much more drastic changes may be needed. Again, I look forward to differing views Thhhommmasss (talk) 18:33, 13 July 2020 (UTC)[reply]

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)[reply]

@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)[reply]
Sure. --Rschen7754 02:26, 23 June 2020 (UTC)[reply]

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 matter the initiatee 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)[reply]
@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)[reply]
@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) 14:46, 28 June 2020 (UTC)[reply]
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)[reply]
I love your continued scaremongering and misrepresentation.  — billinghurst sDrewth 01:59, 8 July 2020 (UTC)[reply]

Closing this RFC

  • With all that said, nearly all of these proposals to reform the RfC process on Meta-Wiki are supported by consensus, with the exception of Proposal 5 (not enough consensus) and Proposal 10 (new proposal, but never got traction because it was put up late). The last edit was made in July 30, and when i gave my !vote to Proposal 10, there is not enough traffic for this to stay active indefinitely on Meta-Wiki. As such, it is in the best interest that this RfC should be closed for good and apply the proposals 1, 2, 3, 4, 6, 7, 8, and 9 - effective after the closing of this RfC. SMB99thx Talk / email! 13:15, 12 August 2020 (UTC)[reply]
    • I disagree with your assessment. Proposal 1 and 5 are on the edge, probably, but they both have the support of a 2/3-majority, if that means anything. Meanwhile, proposal 4 certainly has insufficient support (and proposal 10 can be entirely ignored). In detail:
      • proposal 1: 14 in favour, 7 against with various reasons or one favouring a lower limit (66,6%).
      • proposal 2: unanimous support.
      • proposal 3: unanimous support.
      • proposal 4: 3 in favour, 8 against in various degrees ("not sure", "not yet", "oppose for now", "leaning oppose", "discuss later", "needs more details") (27%).
      • proposal 5: 11 in favour, 5 against, whereof 3 think it should be determined in the general Meta deletion policy (68%).
      • proposal 6: unanimous support except one oppose and one with reservations.
      • proposal 7: 14 in favour, 3 against (82%).
      • proposal 8: There is basically unanimous consent for the proposal, and for adding "An RFC may be withdrawn by its creator, if there are no other users proposing or supporting a proposal different from status quo". Two votes with the "Oppose" template are not actually against the proposal, but in favour of adding some exceptions to it.
      • proposal 9: I will refrain from commenting about proposal 9 for the reasons I already stated there.
    • I have created Requests for comment/Policy as a draft for the outcome of this RFC. Of course I will not close it myself as I have participated in it. --MF-W 02:44, 13 August 2020 (UTC)[reply]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Requests_for_comment/Reforming_the_RFC_process&oldid=24906839"