Requests for comment/Reforming the RFC process
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:
- have a Wikimedia account; and
- be registered for more than three months before making the request; and
- have at least 250 edits globally (on all Wikimedia wikis).
Discussion for proposal 1: For the initiator of the RFC
- 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 · 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]
- This is global, so they could go and edit another Wikimedia wiki. --Rschen7754 19:05, 16 June 2020 (UTC)[reply]
- 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]
- @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]
- 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: 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 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: 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: Reduce to 1 month + 100 edits simply to limit socking, and I might agree. –SJ talk 23:14, 20 June 2020 (UTC)[reply]
- Support --Novak Watchmen (talk) 15:36, 22 June 2020 (UTC)[reply]
- Support per Rschen7754. —MarcoAurelio (talk) 09:37, 24 June 2020 (UTC)[reply]
- Support. Sgd. —Hasley 15:12, 25 June 2020 (UTC)[reply]
- 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. 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. Inexperienced users should not initiate RFC.--Jusjih (talk) 04:53, 9 July 2020 (UTC)[reply]
- 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 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--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 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
- 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)[reply]
- Support, makes sense. Stryn (talk) 15:47, 15 June 2020 (UTC)[reply]
- Support per Rschen7754 and Stryn. ミラP 23:41, 17 June 2020 (UTC)[reply]
- Support · Of course. -- CptViraj (talk) 04:28, 18 June 2020 (UTC)[reply]
- Support, do not see any pitfalls with this part.--Ymblanter (talk) 10:18, 20 June 2020 (UTC)[reply]
- Support --Novak Watchmen (talk) 15:37, 22 June 2020 (UTC)[reply]
- Support. Due process. —MarcoAurelio (talk) 09:38, 24 June 2020 (UTC)[reply]
- Support. Sgd. —Hasley 15:12, 25 June 2020 (UTC)[reply]
- Support Zoozaz1 (talk) 14:46, 28 June 2020 (UTC)[reply]
- Support This more or less should go without saying. 𝒬𝔔 22:35, 28 June 2020 (UTC)[reply]
- Support Das sollte eine Selbstverständlichkeit sein. Grüße vom Sänger ♫(Reden) 05:22, 2 July 2020 (UTC)[reply]
- 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)[reply]
- Support Proposals should be not one sided and must be fair. SMB99thx Talk / email! 11:39, 10 July 2020 (UTC)[reply]
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 for the same reasons as above. --Rschen7754 21:07, 14 June 2020 (UTC)[reply]
- 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)[reply]
- 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)[reply]
- Support per Rschen7754. ミラP 23:41, 17 June 2020 (UTC)[reply]
- Support, do not see issues. What about RfCs which concern WMF?--Ymblanter (talk) 10:22, 20 June 2020 (UTC)[reply]
- Support --Novak Watchmen (talk) 15:37, 22 June 2020 (UTC)[reply]
- Support as above. —MarcoAurelio (talk) 09:39, 24 June 2020 (UTC)[reply]
- Support obviously. Sgd. —Hasley 15:07, 25 June 2020 (UTC)[reply]
- Support Zoozaz1 (talk) 14:46, 28 June 2020 (UTC)[reply]
- Support As with proposal 2. 𝒬𝔔 22:36, 28 June 2020 (UTC)[reply]
- Support Wie bei Nummer 2, das sollte selbstverfreilich sein. Grüße vom Sänger ♫(Reden) 05:32, 2 July 2020 (UTC)[reply]
- Support.--Snaevar (talk) 22:54, 7 July 2020 (UTC)[reply]
- Support Like the proposal 2 and could help enforcing it. SMB99thx Talk / email!
- Support--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 09:51, 18 July 2020 (UTC)[reply]
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 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]
- 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 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 --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 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
- Support because unsubstantiated accusations should not be left on Meta in perpetuity. --Rschen7754 21:08, 14 June 2020 (UTC)[reply]
- Support, we can always remove attacks or nonsense requests, even without this RfC. Stryn (talk) 15:56, 15 June 2020 (UTC)[reply]
- Support I also think that "courtesy blanking" should be listed as an option. WhatamIdoing (talk) 22:41, 16 June 2020 (UTC)[reply]
- 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)[reply]
- Proposals 1-4 are what defines if RFCs are valid. --Rschen7754 01:38, 18 June 2020 (UTC)[reply]
- 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]
- 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)[reply]
- 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)[reply]
- 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)[reply]
- Oppose per Ruhubelent. ProcrastinatingReader (talk) 11:01, 20 June 2020 (UTC)[reply]
- Agreed; invalid or ill-formatted RFCs shouldn't lie around forever. --MF-W 00:34, 21 June 2020 (UTC)[reply]
- Support --Novak Watchmen (talk) 15:39, 22 June 2020 (UTC)[reply]
- 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)[reply]
- Support, per MA. Sgd. —Hasley 15:08, 25 June 2020 (UTC)[reply]
- 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)[reply]
- 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)[reply]
- Support Meta Wikimedia should step up in case of attack or harassment RfCs. These things should never ever be tolerated in these times. By this proposal, we can also deter them from doing such things by denying them of these kind of RfCs. SMB99thx Talk / email! 11:43, 10 July 2020 (UTC)[reply]
- Support and oversighters may redact them in case of problems ThesenatorO5-2 (talk)
- Support --𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 09:50, 18 July 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
- 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)[reply]
- 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)[reply]
- Support Also global sysops. WhatamIdoing (talk) 22:45, 16 June 2020 (UTC)[reply]
- 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)[reply]
- Support, preferably if global sysops are allowed to do so. ミラP 23:41, 17 June 2020 (UTC)[reply]
- 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)[reply]
- Support –SJ talk 23:14, 20 June 2020 (UTC)[reply]
- Support --Novak Watchmen (talk) 15:40, 22 June 2020 (UTC)[reply]
- Support. —MarcoAurelio (talk) 09:44, 24 June 2020 (UTC)[reply]
- Support Sgd. —Hasley 15:08, 25 June 2020 (UTC)[reply]
- Support Zoozaz1 (talk) 14:46, 28 June 2020 (UTC)[reply]
- 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)[reply]
- Support 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)[reply]
- Support. Enchaurages productive comments and keeps the page organised.--Snaevar (talk) 22:54, 7 July 2020 (UTC)[reply]
- Support We should keep ourselves civil for all times. Without civility, harassment might follow. SMB99thx Talk / email! 11:54, 10 July 2020 (UTC)[reply]
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 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)[reply]
- 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)[reply]
- 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)[reply]
- 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)[reply]
- 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)[reply]
- 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)[reply]
- Support, partial blocks are already available--Ymblanter (talk) 10:47, 20 June 2020 (UTC)[reply]
- Support, clarifies something already possible. –SJ talk 23:14, 20 June 2020 (UTC)[reply]
- Support --Novak Watchmen (talk) 15:40, 22 June 2020 (UTC)[reply]
- Support. —MarcoAurelio (talk) 09:46, 24 June 2020 (UTC)[reply]
- Support. Sgd. —Hasley 15:09, 25 June 2020 (UTC)[reply]
- 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)[reply]
- Strong 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)[reply]
- Oppose. There should be an discussion on banning on meta in general before this happens.--Snaevar (talk) 22:54, 7 July 2020 (UTC)[reply]
- Support to deter those just wanting to win over argument without solving the radical problems.--Jusjih (talk) 04:56, 9 July 2020 (UTC)[reply]
- Support to help enforcing proposal 6. SMB99thx Talk / email! 12:10, 10 July 2020 (UTC)[reply]
- Strong support Although the wording of this proposal is unclear, the idea is acceptable. --ThesenatorO5-2 (talk) 03:20, 18 July 2020 (UTC)[reply]
- Support---𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 09:48, 18 July 2020 (UTC)[reply]
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 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]
- I mean the second - but the first could be a valid proposal. --Rschen7754 05:52, 15 June 2020 (UTC)[reply]
- I edited the proposal to reflect this. --MF-W 00:36, 21 June 2020 (UTC)[reply]
- I mean the second - but the first could be a valid proposal. --Rschen7754 05:52, 15 June 2020 (UTC)[reply]
- 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, 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]
- Update: I also endorse GZWDer's idea. ミラP 17:15, 1 July 2020 (UTC)[reply]
- 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. I also support GZWDer addition regarding the withdrawal of RfCs. —MarcoAurelio (talk) 09:47, 24 June 2020 (UTC)[reply]
- 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. There needs to be an order to who closes RFCs.--Snaevar (talk) 22:54, 7 July 2020 (UTC)[reply]
- Support--Jusjih (talk) 04:57, 9 July 2020 (UTC)[reply]
- 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]
- 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]
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. 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. Pretty much spot on.--Snaevar (talk) 22:54, 7 July 2020 (UTC)[reply]
- 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 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 --Novak Watchmen (talk) 12:25, 11 July 2020 (UTC)[reply]
- 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 * 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. 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]
- But what is your opinion? I will just add
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]
- I agree. ThesenatorO5-2 (talk) 09:54, 16 July 2020 (UTC)[reply]
- 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)[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:
- 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)
- 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)
- 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]
- 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]
- 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]
- 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 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]
- 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)[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]
- 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]
- 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 think this is a good idea. --MF-W 21:47, 18 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 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]
- 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]
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]
- 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: