BattleTechWiki:Requests for comment
Welcome to the BattleTechWiki's Requests for comment information page. Requests for comment (RfC) is a process for requesting outside input concerning disputes, policies, guidelines or article content. RfCs are a way to attract more attention to a discussion about making changes to pages or procedures, including articles, essays, guidelines, policies, and many other kinds of pages. It uses a system of centralized noticeboards and random, bot-delivered invitations to advertise discussions to uninvolved editors. The normal talk page guidelines apply to these discussions. If you have an article creation or research question, please consider posting to the Research Desk.
- To submit a Rfc, please use this page BattleTechWiki:Requests for comment/Submissions (BTW:RFC/S).
- A list of RfCs that require much more than a simple discussion and are being worked on can be found at BattleTechWiki:Requests for comment/Active Requests (BTW:RFC/A).
- An archive of (selected) past RfCs and other discussions can be found at BattleTechWiki:Requests for comment/Completed Requests.
What an RfC is
A request for comment (RfC) is a request to the BattleTechWiki community for comment on an issue. Often, the issue is what an article should say. Sometimes it is a proposal for a BattleTechWiki process or rule change. RfC invites comment from a broader selection of editors than a normal talk page discussion.
Because BattleTechWiki makes decisions by consensus, an RfC can act as a dispute resolution, especially when combined with discussion closure. If, for example, the editors of a certain article cannot agree on whether a certain fact should be included, they can use an RfC to find out what the community thinks and, if a consensus emerges, that usually resolves the dispute.
Before starting the process
RfCs are time consuming, and editor time is valuable. Before using the RfC process to get opinions from outside editors, it's often faster and more effective to thoroughly discuss the matter with any other parties on the related talk page. Editors are expected to make a reasonable attempt at resolving their issues before starting an RfC. If you are able to come to a consensus or have your questions answered through discussion with other editors, then there is no need to start an RfC.
If a local discussion does not answer your question or resolve the problem, then some other forums for resolution include:
- If the article is complex or technical, it may be worthwhile to ask for help at the relevant WikiProject.
- If more than two editors are involved or the issue is complex, you could use our official discord in order to ask for outside opinions.
- If you are report spam, page blanking, and other blatant vandalism, see BattleTechWiki:Vandalism.
If you are not sure if an RfC is necessary, or about how best to frame it, ask on the talk page of this page.
Creating an RfC
An RfC takes the form of a section that is created on BattleTechWiki:Requests for comment/Submissions (BTW:RFC/S). Once the section is created. This "RfC discussion" takes the form of an ordinary BattleTechWiki talk page discussion that follows the normal rules and procedures. Closing the discussion, in which a normally uninvolved neutral editor declares the discussion finished and summarizes its conclusions, is often of particular value in an RfC, as the purpose of an RfC is usually to develop a consensus about some disputed point.
There are many acceptable ways to format an RfC. Below is one example of how a simple RfC could appear. This example will work best for average or smaller RfCs.
You can copy and paste this example, but be sure to change the wording to reflect your particular topic (for example, the "hist" category may need to be changed). A signature ("~~~~") or at least a time and date ("~~~~~") is required. Do not include any opening html tags (e.g.,
<small>) in the initial RfC statement unless its corresponding closing tag (e.g.,
</small>) also comes before the first timestamp, i.e., don't "straddle" the first timestamp inside html code, otherwise it may corrupt the entry of the RfC on the topic discussion pages. After you have inserted text similar to this into the talk page, you must publish the page.
== RfC about including an image in the history section ==
Should the "History" section contain a image of the building of the ship? ~~~~
Statement should be neutral and brief
Keep the RfC statement (and heading) neutrally worded and short. The statement itself needs to be neutrally worded and brief. After the request section has been made, you should follow normal talk page rules, which allow you to be verbose (within reason) and as non-neutral as you want. Statements are often phrased as questions, for example: "Should this article say in the lead that John Smith was a contender for the Pulitzer Prize?" The statement should be self-contained, and should not assume that the section title will be descriptive enough.
If you have lots to say on the issue, give and sign a brief statement in the initial description and publish the page, then edit the section again and place additional comments below your first statement. If you feel that you cannot describe the issue neutrally, you may either ask someone else to write the question or summary, or simply do your best and leave a note asking others to improve it. It may be helpful to discuss your planned RfC question on our official discord before starting the RfC, to see whether other editors have ideas for making it clearer or more concise.
Responding to an RfC
All editors (including IP users) are welcome to respond to any RfC.
- Responses may be submitted in a variety of formats. Some RfCs are structured as a series of distinct responses, one per editor. Others result in a threaded (indented) conversation involving multiple editors.
- Edits to content under RfC discussion may be particularly controversial. Avoid making edits that others may view as unhelpful. Editing after others have raised objections may be viewed as disruptive editing or edit warring. Be patient; make your improvements in accord with consensus after the RfC is resolved.
- Remember that BattleTechWiki is an encyclopedia; all articles must follow the Neutral point of view, Verifiability, and No original research policies.
- Try not to be confrontational. Be friendly and civil, and assume good faith of other editors' actions.
- If you feel an RfC is improperly worded, ask the originator to improve the wording, or add an alternative unbiased statement immediately below the RfC question. Do not close the RfC just because you think the wording is biased.
- Mediate where possible—identify common ground, and attempt to draw editors together rather than push them apart.
- If necessary, educate users by referring to the appropriate BattleTechWiki policies or style page.
As an RfC is the solicitation of comment in a discussion, ending an RfC consists of ending that solicitation. When an RfC is used to resolve a dispute, the resolution is determined the same way as for any other discussion: the participants in the discussion determine what they have agreed on and try to implement their agreement.
An RfC should last until enough comment has been received that consensus is reached, or until it is apparent that it won't be. If one of the reasons to end RFCs applies, someone should archive it , as soon as it is clear the discussion has run its course.
Reasons and ways to archive RFCs
Like other discussions, RfCs sometimes end without an agreement or clear resolution. There are several ways in which RfCs end and are archived:
- The question may be withdrawn by the poster (e.g., if the community's response became obvious very quickly). In this situation, the editor who started the RfC would normally be the person to remove the the section that was created for them.
- The RfC participants can agree to end it at any time.
- The dispute may be moved to another page
- Any uninvolved editor can post a closing summary of the discussion; if consensus is undoubtedly clear, any editor involved may archive the discussion.
- The discussion may just stop and become stale. In this case it may be safely be archived.