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.
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.
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.
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.
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:
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".
RFCs are a fairly open framework, and various types of structure can be used. Some of the ways you can format an RFC follow.
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.
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.
Exactly what you should be doing during the RFC is of course context specific, but there are some general ideas to keep in mind.
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.
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.
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.
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.
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.
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.
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:
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".
RFCs are a fairly open framework, and various types of structure can be used. Some of the ways you can format an RFC follow.
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.
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.
Exactly what you should be doing during the RFC is of course context specific, but there are some general ideas to keep in mind.
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.
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.