User:Just Step Sideways/The perfect policy proposal

This page in a nutshell: I have created several of the more widely attended and controversial RFCs of the past. Learn from my mistakes. Or turn back now if you want life to be easy.

Many users shy away from initiating a request for comment on any policy issue likely to be controversial or divisive. With a few pointers to guide you from the store of my own experience with such processes you can overcome these fears and take on the truly tough issues.

users calmly discussing a policy proposal with the helpful individual who advanced it

Prerequisites

Forget it. You will never draft the perfect policy RFC. It can't be done. Somebody in this world will think that it sucks, and will tell you so in the most snide, condescending way they can manage. If you can't handle that stop reading right here. You'll only end up feeling sad and rejected, and I honestly don't want to see that happen to you.

For your own good, just accept things the way they are and go back to whatever it was you were doing before you lost your mind and decided you wanted to change something important on Wikipedia.

Still here? You sure? You know your idea is terrible, you should be be blocked for even suggesting it, and your proposal reads like it was written by a macaque with a brain injury, right? Are you sure you want to keep going?

All right, let's get down to business.

It is best to have a specific, concrete idea to start from. Just opening the doors and saying "let's have a discussion" rarely yields useful results.
Is your idea stupid?
Really think about it. Really. Is it stupid? Be open to the possibility that you may have had a stupid idea. It happens. You may be really wrong about what the community thinks about the issue you are trying to address. You may have identified a real problem but come up with a solution that won't actually help. You may have been tired, cranky, or drunk when you thought up the idea and when you think about it the next morning it suddenly reveals itself to be a bad idea. Be sure that at the very least you, as the proposer, are positive that it is not.
Ok, now take that idea and follow it through. What is it intended to accomplish? What is needed to implement it? Who would be responsible for enacting it? Are there any technical issues with the software? Will the WMF even let you do it? Is it legal in the United States?
Now that you know what it is you are actually trying to accomplish you are ready to try and write a proposal.

Your proposal

Don't try to just type something up in a few minutes. Take your time. Write it, read it, walk away, read it again, fix it, read it again, start over, walk away again, and so forth. Keep it up as long as you need to.

Be clear about what would change and why it should change. Be specific, but not insulting or condescending. Be painfully polite and specific in your proposal language.

"Be specific" does not mean "describe what would happen in every conceivable situation." Express the general idea. The details will almost certainly evolve over time anyway.

Consider the order in which you present information carefully. Is it wiser to explain the change or the intended effect first? Try re-arranging the order and see if it is more compelling one way or the other.

Planning the RFC

Now that your proposal is developed you are ready to prepare it to be presented it to the community. Remember that although you have a goal in mind the point of the RFC is to determine what the community thinks of the proposal, not to push through your desired result.

Be prepared to be involved with your chosen issue for a long time. Even fairly minor RFCs are usually left open for thirty days. For big policy changes you can expect the process to take significantly longer, even years, to accomplish. The first RFC may not get anywhere or may require multiple phases spanning a long period. You are trying to make a big change here, be realistic with yourself: it is not going to happen overnight, if it even happens at all.

timing

In a perfect world it would make no difference when you open your RFC. Then again, in a perfect world we wouldn't need it to begin with. Things to avoid:

The "holiday season". That would be late November through early January. People are busy at this time. Also a lot of them are drunk and/or cranky. Drama always goes up during this period. Bad time to try and make an important decision.
Overlapping while there is already an RFC or other policy discussion going on that is closely related to the subject you wish to discuss. Seeming over-eager or impatient about your RFC is a good way to derail it yourself.
Under a cloud, that is while either you yourself or the issue you wish to discuss are the subject of ANI drama, an ArbCom case, etc. People will assume "sour grapes" and be less willing to support the ideas, or even discuss it.

This isn't to say you cannot or should not work on it during such times, just keep it on a user subpage or something until the time is right to "go live".

format

RFCs are a fairly open framework, and various types of structure can be used. Some of the ways you can format an RFC follow.

Unformatted discussion You present your proposal and ask people to comment on it. Hopefully they do so. This is the simplest form of RFC. It works reasonably well for content issues or minor policy changes but for big issues it can rapidly become a tangled, repetitive mess. If you are anticipating a large volume of responses this probably is not the way to go unless you are planning it as the opening of a multi-phase RFC.

Straw poll You present your idea and ask users to either support or oppose it with brief statements. This can be good for establishing basic levels of support but it is lacking in nuance. Straw polls are often accompanied by an open discussion to overcome this issue. A straw poll by itself is unlikely to be seen by the community as a sufficient process for gaining approval of major policy changes.
Position statements Multiple positions are presented and the community is asked to endorse statements they agree with. Depending on the nature of the issue this can work well or can be very, very messy. When we tried to come up with a community de-admin ship proposal we wound up with seventeen competing proposals. Guess what? No consensus was found. For the 2012 Pending Changes RFC I came up with a more restricted version of this format, where only three, mutually exclusive positions were presented and adding of new positions was not permitted. This worked in that it forced a usable result but there were several users who objected to the inability to make alternate proposals. This restricted version is only meant to be used in a similar situation, where multiple, widely attended previous RFCs over an extended period of time had failed to come to a consensus. If you go for this format on the first attempt you will be seen as trying to force your desired outcome. In fact I was accused of that by many at the PC RFC. Apparently I have the ability to control the minds of hundreds of other Wikipedians, and force them with my devilish trickery into endorsing my preferred position. Expect that sort of thing to happen to you to. I can't stress it enough that you and your alleged motivations will be attacked no matter how carefully you proceed.
The questionnaire A series of questions are presented and users are asked to create their own subpage and supply their answers to as many as they like. I really like this format as it is non-confrontational, but some users will be appalled that you did not use scientific methodology to construct the questions, as if determining consensus for policy changes is ever a scientific process. An important lesson I learned from the never-really-got-anywhere civility enforcement RFC is to find some way to have the questions reviewed by a group of at least four or five users before proceeding. Get their feedback on the questions and alter them as appropriate There will still be people who will hate what you have put together, but you will be able to honestly say that the questions were reviewed before being posted. The biggest objection I got was that the questions were leading. Puzzlingly, when I asked where users thought they were being led they seemed reluctant to say. The few that did say contradicted one another, so I took that to mean that they were projecting their own opinions and imagining a hidden subtext that really was not there. Sometimes getting helpful feedback on this project can be extremely difficult, although getting unhelpful angry ranting feedback is a piece of cake. Anticipating objections is an important part of structuring your RFC, but remember you can't please everyone.
The brilliant new format There are not any actual rules that dictate how an RFC is structured. If you think you have a better idea than any of these, put it together, maybe have a few people you trust to be fair and honest look it over and give feedback. Who knows, you might end up changing the very way we approach decision making.

Administration

Before you go live with your RFC put some thought toward who will be administrating the process and closing it when it is complete. It won't be you, you are too involved. Consider recruiting a closer or even a team before opening the RFC. Try to find trusted users or admins who have not expressed any strong opinions on the issue being discussed. A posting at WP:AN can help you recruit such users. Discuss with them exactly what their responsibilities will be during and after the RFC. Have them review everything again before going live.

If you have any type of hard data you plan to use, find one of those users who loves creating graphs and see if you can get them to make some using your data. Quantifiable data is the best way to combat some of the more ridiculous criticism you are about to be subjected to and graphs make your RFC look good.

Last chance

Stop for a moment and consider one last time the possibility that your idea is stupid, or badly out of step with what the community expects, or just unworkable. Try to look at it with fresh eyes, as if you were arriving at the RFC as a skeptic. Remember that you are about to open yourself up to months of gratuitous verbal abuse and wild accusations for the sake of this process. Still feels like a good idea? You're dumber than I thought, go ahead and open the RFC.

During the RFC

Exactly what you should be doing during the RFC is of course context specific, but there are some general ideas to keep in mind.

State your case, make sure you have been clear about what it is you propose. If it is a poll or a position statement RFC add your endorsements. Then do your best to shut up and let the community discuss the matter.
If questions arise about the format, (and they almost certainly will no matter which you have chosen) they should be discussed on the talk page. Explain the structure and why you chose it, but don't let yourself get drawn in to a long debate about it unless it is clear that large portions of users are objecting instead of participating. There will always be a few who will argue about how whatever format you have chosen is not good. Do your best to assuage their concerns but remember that some people don't want to like it for whatever reason. Maybe they don't like the way consensus is going and want to derail the process, or maybe they just don't understand the nuances, or they have a new idea they like better even though your RFC is already open, or maybe they just like to complain. Remember you can't please everyone.

User:Cmanson 69 thinks you have some bad ideas in your head

This is the part where you and your motivations will begin to be attacked. Don't say I didn't warn you. Be sure to point out whatever steps you took before the RFC opened. If you have dedicated coordinating admins advise everyone of who they are. Don't argue with people who accuse you of acting in bad faith. You aren't, right? So just ignore them.
The worst thing you can do is try to argue with every single user who does not fully support your position. So, as a reminder, shut up.
You did all that planning beforehand to try and avoid problems later, but don't begin for a second to believe you have prepared for every contingency. Be flexible if the situation changes during the course of the RFC. Even though you created it, it is not yours. If the community wants it changed, it will change.
Relax. The hard part is (probably) over. Go do something else for a while, don't check the RFC every time there's a new post, once every day or so is all the attention it needs.

After the RFC

Hopefully there is not much left to do. If you had a closer or closers lined up beforehand the ball is in their court now. If it was a particularly long and contentious discussion it maybe a while before there is a close posted. Be patient.

Did it succeed?

Success in this context is a result, any result, even if it is not the one you would have preferred. If you have a result, you have succeeded and you should be proud of that. If it wasn't the result you wanted, don't throw a fit about it. Remember that consensus can change, maybe at some point in the future the community will be more receptive to your preferred result. For now you have a consensus, so the community has benefited from your efforts and that is a good thing.

"No consensus" is basically a failure. Not your failure mind you, but the issue is not resolved and so the community has failed to address the issue. I warned you this might happen. Walk away for a minute if it is making you angry. Either do something else on-wiki or, better yet, turn the computer off and do something else entirely for a while. Once you are less annoyed by it, take a look back at the process and see if you can determine why a concrete result was not achieved. Was it the structure, the timing, some unexpected event, or is the community just not able to make up its mind about this? Don't rush into a new process. Give it time. In a few months or even a year maybe try again, using what you learned from this process to inform how the next process will work.