Wikipedia:Requests for comment/RFC

This Request for Comment concerns how Wikipedia's Requests for Comments (RFCs) can be improved. The BLP RFC is a notable recent example illustrating the need to improve the workings of RFC on issues that involve largescale participation.

Problems with current practices

• Listing of viewpoints by individual names.
• Reinforces the idea that an editor must choose a position and then defend it, rather than working toward consensus
• Non-neutral opening statements
• Lack of clarity or agreement on the purpose of a specific RFC
• Discussion on both talk page and project page.
• Self-reinforcing -- for example, this *can* happen when asking whether there is a consensus.
• Proposals unlikely to attain consensus remain on the table
• Encourages the formation of factions

Possible solutions

• Get at root question.
• Moderation or facilitation.
• Clear separation of what goes on project page and what goes on talk page.
• Frequent summaries.
• Don't !vote too early; allow for brainstorming and deliberation.
• Visible, clear, concise and neutral summary for newcomers to the discussion.
• Archiving guidelines. Regular archiving.
• Consider renaming from "Request for Comment," maybe to "Request for Discussion," etc.
• "Fail quickly", that is, discard ideas with significant opposition so that they can be replaced with a more refined version or a compromise.
• An iterative process instead of trying to solve everything at once.
• "Requests for moderator"?
• Look for and work toward common ground.
• Look for ways to trade off, negotiate.

Kill Bad ideas quick?

How can you know quickly something should be killed? Sometimes pushing boundaries is useful. — Preceding unsigned comment added by Maurreen (talk • contribs)

The idea behind "kill bad ideas quick" is that if an idea is meeting significant early opposition, the chance that it reflects consensus is almost nil. It should be easy to withdraw that proposal and propose a new one that might reflect consensus. The process should support this kind of iteration. (Promoted to subsection for discussion) Gigs (talk) 13:27, 11 March 2010 (UTC)

How about changing "bad ideas" to "ideas with negligible support"? Maurreen (talk) 14:53, 11 March 2010 (UTC)

Fine with me. Gigs (talk) 16:56, 11 March 2010 (UTC)

I like this idea. -- Eraserhead1 <talk> 13:28, 28 March 2010 (UTC)

This is a perfect illustration of the way Wikipedia has everything ass-backwards. The point of "consensus" is to make sure that minorities are not trampled by majorities. Instead, Wikipedia uses "consensus" as a tool for crushing dissent, unorthodoxy, and unpopular minorities. And this is why Wikipedia has a reputation for being a thuggish clique of malevolent Trekkies. SmashTheState (talk) 07:38, 31 March 2010 (UTC)

Collaborative Views

Problem: Whilst Wikipedia is based on collaboration in mainspace, RFCs are based on views expressed by individual editors. This leads to confusion as RFCs grow; the big picture is lost as overlapping and partially contradictory individual views proliferate. Clear outcomes become hard to achieve, and discussion is lost in favour of (!)voting.

Solution: One way to improve "Large RFCs" (TM) would be to split them in two in the following way.

1. Individual views are initially expressed in the usual way.

2. At some point, if things become complicated enough (they won't always), someone may split off a subpage: RFC X/collaborative views.

a. This page would seek to develop a number of different views, combining the views of different individual editors. Each view can be edited by anyone in a constructive way. The total number of views should be kept as low as possible and as high as necessary.

b. It will be helpful to have each collaborative view on its own subpage, with the view transcluded into RFC X/collaborative views. This gives each view its own talk page and page history - familiar tools that then become more useful. Care would need to be taken not to split discussion too much - some splitting will be helpful, but not too much. The talk page of the main collaborative views subpage, RFC X/collaborative views should be used for general discussion.

3. Both pages develop in parallel; new individual views may continue to be added.

4. Since the collaborative views evolve in a way that individual ones don't, endorsements of these may be affected; people may endorse something they later wish not to, or hold off endorsing to see how it goes. So some time before the RFC closes (eg after 3 weeks, with 1 week left), stable versions of the collaborative views should have been reached, and they should be closed for editing. Participants can then endorse the stable views. If a stable version can't be identified, views should be split such that competing variations of a view can be endorsed. In this case it will probably be helpful to in some way clearly identify the views as variations.

This sounds a bit complicated, but it isn't really. The apparent complication, such as it is, arises from trying to precisely describe an unfamiliar process which should be pretty obvious in use because it structures discussion using tools and techniques which are very familiar from elsewhere. The only tricky part is the endorsements; it would need to be seen in practice how hard that it is; but it's basically a solvable problem, whilst the forest of discussion that arises from current Large RFCs is not. Rd232 ^talk 19:16, 2 March 2010 (UTC)

How meta. I like the idea of collaborative statements for RfCs, we should take advantage of the fact that we are a wiki more often in our discussions (I suggested it before for AfD). I don't think they should be made on separate pages, the problem with both the BLP RfC and the CDA RfC was too much splitting and discussion of discussion of discussion, which leads most editors to drift away. Fences&Windows 01:15, 3 March 2010 (UTC)

Yes, it's a risk. But if the splitting is well-structured (unlike the RFCs you mention), the risk is less, and may be worth it. Hard to know without actually trying something in that direction. Rd232 ^talk 22:24, 3 March 2010 (UTC)

• I propose a RFC so that we can discuss the ramifications of this RFC :-P More seriously, the consensus-based style of decision breaks down as the number of discussants becomes large. We more or less implicitly recognize this, what with elections for ArbCom, RfA, etc. I think it's not unreasonable to use RFCs to solicit comment, but actual controversial policy proposals should probably be put to some kind of vote. I note that this more or less seems to be our practice, although the framing of our de facto votes could use improvement. Ray^Talk 18:56, 3 March 2010 (UTC)

• I agree that the BLP RFC is a mess, and that making sections for opinions of different people is not the best way. But I think forking is counterproductive. ... The idea behind Wikipedia:Community Facilitation was good, but it seems like that didn't get off the ground. ... I had started to start a page on "how to hold an effective discussion". ... One point is that I think the root question is important, and sometimes that is overlooked. What is the root question here? Maurreen (talk) 01:53, 4 March 2010 (UTC)

The root question here is how can we better aggregate individual views in a constructive, debate-enhancing way to enable a well-thought-out and clearly agreed collective decision. Also, I wouldn't characterise my suggestion above as "forking" at all; there is a clear division of labour, with the talk page of individual proposals being for developing that proposal, and talk page of the collaborative subpage for general discussion (and the talk page of the initial RFC for discussing individual views). If that's felt to be too much, the relevant talk pages can be redirected, or the collaborative views developed on the one single page. I've specified an implementation that I think will work, but it's the basic idea which is important. Rd232 ^talk 12:15, 4 March 2010 (UTC)

Thanks. If something like what you propose were to happen, one thing that would make more sense to me would be to make it to "sides" of the same place -- the discussion on the talk page, and the other part on the project page. (Forgot sig earlier.) Maurreen (talk) 17:09, 7 March 2010 (UTC)

I think the model layout out at WP:IECOLL worked well . Gnevin (talk) 16:21, 10 March 2010 (UTC)

I hope you are not seriously suggesting that massive and complicated voting is a good way to solve anything in particular. That Ireland mess was not something that should be repeated. Gigs (talk) 13:46, 12 March 2010 (UTC)

I meant the no rebuttal statement of opinions was easy to understand and didn't turn into a massive super long discussion thread. The voting was a joke Gnevin (talk) 18:54, 14 March 2010 (UTC)

No rebuttal was the idea behind the traditional RFC of statement-endorse with no oppose sections. What we see is that if someone is upset enough then oppose sections get added anyway. If people had "clerked" the oppose sections on the BLP RFC to the talk page, then there would have probably been a lot of screaming. Gigs (talk) 00:10, 15 March 2010 (UTC)

Planning from the outset - a case study

At Talk:Kiev we had a perennial request to move the article from Kiev to Kyiv. When this was raised for the umpteenth time (with no significant new evidence or new argument), to save us the normal fortnight-long rehash of exactly the same material, we decided to try out a new decision-making process - and it worked really rather well.

Instead of allowing the normal unorganised free-for-all of opinions from the start, we started with a few days' fact-finding. All relevant outside data, policies and preceding arguments were collected together in an organised fashion, with full links provided. Commenting on the material was actively dissuaded and removed at this point, with the reminder that everyone would get the opportunity in due time after this phase. Then, when parties were satisfied all relevant material was at hand, discussion was started.

Why did this work better? I believe for the following reasons:

1. arguments were focused on specific points of evidence rather than general opinions
2. it was very easy for any closer to identify and ignore specious arguments and rhetoric not actually based on the facts at hand
3. the important matters of discussion were obvious from evidence collected, so the discussion was focussed right from the outset
4. old arguments were not rehashed - they were already written down, with explanation of why they were supported or rejected
5. more time was taken to consider the evidence and make a nuanced, stronger case rather than make reflex judgements
6. comments were generally shorter, because of the easy reference to the evidence and previous arguments - the bane of the popular RfC is the sheer volume of text.

To see this process in action, see this archive.

Overall I believe that a mid-term collation and distillation of arguments is no bad thing, but I believe that initialising the RfC in a manner similar to that we did at Kiev could help keep the discussion along more focused lines right from the outset. A combination of the two ideas might work very well. Knepflerle (talk) 16:47, 5 March 2010 (UTC)

That makes a lot of sense. It won't be always exactly applicable, but the idea of planning and following the plan overall is widely applicable. Maurreen (talk) 21:31, 5 March 2010 (UTC)

Bad examples

• Wikipedia:Requests for comment/Biographies of living people and some directly-related discussions Maurreen (talk) 23:20, 4 March 2010 (UTC)

• No kidding. Calliopejen1 (talk) 17:07, 7 March 2010 (UTC)

Good examples

• Wikipedia:Community de-adminship/RfC? Maurreen (talk) 23:20, 4 March 2010 (UTC)
• Wikipedia_talk:Username_policy/Blatant_Promotion_RfC -- This one worked pretty well, but it was a smaller group of editors. Closing proposals early where there was obviously no consensus for them forming helped focus the discussion. Leaving dead proposals open on the off chance that the opposition could be massively outvoted is an instinct based on the idea that it is indeed a vote. "Kill bad ideas quick" would be a good rule of thumb to aim for, so that they could be reformulated into something that approaches consensus. Gigs (talk) 20:08, 10 March 2010 (UTC)
• Kiev naming dispute -- Instead of allowing the normal unorganised free-for-all of opinions from the start, we started with a few days' fact-finding. All relevant outside data, policies and preceding arguments were collected together in an organised fashion, with full links provided. Commenting on the material was actively dissuaded and removed at this point, with the reminder that everyone would get the opportunity in due time after this phase. Then, when parties were satisfied all relevant material was at hand, discussion was started. (Also see separate section of this page, for more detail.)

Miscellaneous, or haven't thought of a better name

I don't understand the thinking behind "no rebuttal."

But I think the idea of "statement -- endorse" is not generally applicable. For one thing, it gives little support to brainstorming. Maurreen (talk) 00:30, 15 March 2010 (UTC)