Requests for comment/Process/Draft

The Wikimedia RFC Process is used to facilitate technical decisions or complex changes that are strategic, cross-cutting, and/or hard to undo. Read more about the scope in the TechCom Charter.

Overview
The RFC (Request for comments) process provides a structured workflow for contributors to solicit qualified feedback on a technical proposal. It collects all ideas in one place and it documents whether ideas will be worked on or were discarded, and why.

Note that most changes to Wikimedia software (including MediaWiki), such as bug fixes and enhancements, should not follow the RFC process, but should instead be discussed in the software's issue tracker and/or be submitted as Git patches and follow the normal code review process.

An RFC may be declined if it is believed to be out of the defined scope. If it doubt, consult with TechCom. TechCom members manage the review process and have the authority to approve or decline RFCs.

Start an RFC
RFCs take the form of a task on the #TechCom-RFC Phabricator workboard.

To file an RFC task, use the Start an RFC task template.

Phase 1: Define
Under the "Motivation" section, define the problem(s) you are seeking to solve with this RFC, and specify the requirements that proposals should meet.

If the exact scope and requirements are not yet known, feel free to leave this open. You can ask for feedback on Wikitech-l. Another option is to discuss the RFC with other people during an IRC chat (see RFC review meetings).

Once the problem space and desired outcome or acceptance criteria are filled in, the RFC can proceed to Phase 2. To do so, anyone may move it there on the Phabricator workboard.

Phase 2: Resource
At this point the following should be determined:


 * Product owner(s) for the affected or proposed project(s).
 * Code steward for the project.
 * Developer(s) for the initial implementation.

For RFCs that propose a new development policy, the above does not apply; In general TechCom is available to help write the documentation for new policies. If that is not the case, then it should be determined on the task who will draft the documentation instead.

Once the direction is resourced, the RFC enters Phase 3 (move it on the Phabricator workboard).

Phase 3: Explore
In this phase an explicit effort should be made to reach out to hear from stakeholders, engineers, etc. Ask yourself:


 * Who should be aware of upcoming developments in this area?
 * Who should be in this conversation that isn't yet?

This is when interested persons should consider the different directions this RFC could take and actively draft proposals. These should be described in the comments on the task. To iterate on longer or more complex proposals, you may want to use a wiki page on mediawiki.org instead (Create a personal sub page, and link your proposal from a comment on the task). Keep the discussion central on the task Phabricator.

Once the authors have heard from the stakeholders they need to hear from, and have a selected at least one proposal that meets the requirements, the RFC enters Phase 4 (move it on the Phabricator workboard).

Phase 4: Tune
This is where the author and other participants narrow down which proposal to pursue and make it more concrete. Any concerns that have previously not been explicitly addressed but thought to work out somehow, should be worked out at this point. This is also a good time for stakeholders to confirm that any concerns they raised about the general direction have been accommodated.

Review the proposal(s) against the Architecture Principles and identify any areas that warrant improvement or further discussion.

Once the stakeholder concerns and the Architecture Principles have been addressed, the author should indicate which proposal they want to move forward and request a Last Call. TechCom reviews requests weekly and should review new requests within two weeks. When TechCom has completed their Last Call review and reached a consensus, it will either express any concerns it found, or start the Last Call.

Phase 5: Last Call
TechCom will ensure that The Last Call status is reflected on the TechCom-RFC workboard and announced in the TechCom Radar.

In this final phase, all stakeholders, current and new participants, have two weeks to introduce new concerns. If no new significant concerns were raised and if no substantive changes were made to the RFC proposal, then TechCom will close the RFC. Otherwise, the RFC may continue in the Tune phase.

To ensure that stakeholders are able to give RFCs the attention they deserve, at most two RFCs may be on Last Call at any given time.