Wikipedia:Requests for comment/Example formatting
There are multiple formats for Requests for comment. Some options are shown here. All of these formats are optional and voluntary.
Most popular
The most popular option is a single section containing all information and responses of any kind.
==RfC: Is the photo in the History section relevant?==
{{rfc|hist}}
Should the "History" section contain a photograph of the ship? ~~~~
Separate votes from discussion
If you expect a lot of responses, consider creating a subsection, after your signature, called (for example) "Survey," where people can support or oppose, and a second sub-section called (for example) "Threaded discussion," where people can discuss the issues in depth. You can ask people not to add threaded replies to the survey section.
This format encourages respondents to place a "vote", rather than engaging in a discussion, sharing alternatives, or developing compromises. It is most suitable for questions with clear yes/no or support/oppose answers, such as "Shall we adopt this policy?", rather than open-ended questions, such as "What kinds of images would be suitable for this article?" This style is commonly used for RfCs that attract a lot of responses, but is probably overkill for most RfCs.
An RfC using this structure might look like this:
==RfC: Is the photo in the history section relevant?==
{{rfc|hist}}
Should the "History" section contain this particular photograph of the ship? ~~~~
===Survey===
* '''Support''' inclusion of the photograph, which helps the reader. ~~~~
* '''Oppose''', it isn't relevant enough. ~~~~
===Threaded discussion===
* I have concerns about this photograph. ~~~~
** What kind of concerns? ~~~~
Pro and con
For a question that has a "yes" or "no" answer, and people known to support each of the sides, then this side-by-side approach can offer a balanced view:
==RfC: Is the photo in the History section relevant?==
{{rfc|hist}}
The "History" section talks about a ship. Should the "History" section contain a photograph of the ship? ~~~~
{| class="wikitable"
|+ Should the "History" section contain a photograph of the ship?
|-
! {{yes}}, this is a good idea.
! {{no}}, we should not add this.
|-
| scope="col" width="50%" | This is the best idea since sliced bread. It complies with all our policies and is sure to improve Wikipedia.
| scope="col" width="50%" | This is the wrong idea, at the wrong time, on the wrong page. Also, the proposers haven't suggested any sources yet.
|}
which produces the usual section heading, RfC tag, and question, followed by this table:
| Yes, this is a good idea. | No, we should not add this. |
|---|---|
| This is the best idea since sliced bread. It complies with all our policies and is sure to improve Wikipedia. | This is the wrong idea, at the wrong time, on the wrong page. Also, the proposers haven't suggested any sources yet. |
Responses to the question should be placed under the table; a subsection heading such as ===Comments=== may be added if desired.
What to do about the date stamp: Tables will break the entry on the RfC listing pages, because their pipes are considered to be parameter separators by the RfC listing template. When a table like this is used as part of the RfC opening statement, both the {{rfc}} template and the timestamp (whether ~~~~ or ~~~~~) should both be placed before the table. At any point, you can add a signature without a date by typing ~~~ if you want to show who wrote the statement.
This format is best when the "pro" and "con" comments are limited to short "headline" length summaries of the main points for and against the proposal. If you need to explain your reasons in detail, or if you have a reason that other people don't necessarily agree with, then add them underneath the table, as part of your own signed comment.
Separate support and oppose opinions
Sometimes it's useful to separate opinions according to whether the person is basically for or against something. This style is most commonly used when only a majority vote matters, and the quality of the arguments is relatively unimportant. This approach forces every participant to pick one side or the other, so it is only appropriate if the choices are binary (e.g., yes or no, with no possibility of middle ground). Avoid using this style unless you expect a significant number of responses, and you actually need to be able to count the (numbered) votes.
This type of RfC layout might look something like this:
==RfC: Should we re-design our WikiProject page?==
{{rfc|hist}}
I propose re-designing WikiProject History's main page. Do you support this? ~~~~
===Support===
# '''Support''' redesign. ~~~~
# '''Support''' as long as we keep the links to the article statistics. ~~~~
===Oppose===
# '''Oppose''' as unimportant. ~~~~
# '''Oppose''' ~~~~
===Discussion===
I have concerns about this proposal. I want to [[WP:BIKESHED]] the design before agreeing to anything. ~~~~