tor-browser

The Tor Browser
git clone https://git.dasho.dev/tor-browser.git
Log | Files | Refs | README | LICENSE

README.md (2932B)

The RFC Process

An RFC (Request For Comments) is a process through which contributors can solicit buy-in for proposed changes to the codebase and repository at-large. It was introduced in the first RFC, 0001-rfc-process, which includes additional details about the reasoning for including the process.

This is an overview of what kind of changes benefit from or require the consensus-building that the RFC process provides, as well as a brief guide on how to draft them.

What kinds of changes require an RFC?

  1. Will this result in more engagement with RFCs?
  2. Will this result in more engagement with RFCs?
  3. Will this result in more engagement with RFCs?

What kind of other changes can an RFC be useful for?

  1. Will this result in more engagement with RFCs?
  2. Will this result in more engagement with RFCs?

How to contribute an RFC

There is a template that can be a useful guide for structure.

While drafting a proposal, consider the scope of your changes. Generally, the level of detail should match the level of impact the changes will have on downstream consumers of APIs, other teams, or users.

Once a proposal is drafted:

  1. Will this result in more engagement with RFCs?
  2. Will this result in more engagement with RFCs?
  3. Will this result in more engagement with RFCs?
  4. Will this result in more engagement with RFCs?

Stakeholders

Stakeholders are required for each RFC. They will have the final say in acceptance and rejection. Include at least 2 people as stakeholders: a CODEOWNER of the affected area and another (preferably a Firefox for Android team member).

Stakeholders should be active in the RFC process - they should ask to be replaced if they do not have bandwidth to get the RFC finished in a short time span. This is to help the RFC process remain nimble and lightweight.

Deadlines

A deadline for feedback should be included in each RFC. This should usually be at least a week, so plan accordingly. For more substantial changes, it can be useful to plan for 2 or 3 weeks so that there is more opportunity for feedback from people that are not stakeholders. If a proposal is approved by all stakeholders earlier than the deadline, the proposal can be merged immediately.