JoJo
/
LeOS-Ice-browser
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 1 Wiki Activity
LeOS-Ice-browser/android-components/docs/rfcs
History
harvey186 7a6de5f3e6 v131 2024-10-12 11:57:06 +02:00
..
0000-template.md v131 2024-10-12 11:57:06 +02:00
0001-rfc-process.md v131 2024-10-12 11:57:06 +02:00
0002-browser-search-rewrite.md v131 2024-10-12 11:57:06 +02:00
0003-concept-base-component.md v131 2024-10-12 11:57:06 +02:00
0004-top-sites-feature.md v131 2024-10-12 11:57:06 +02:00
0005-migrate-sitepermission-ac-store-geckoview-store.md v131 2024-10-12 11:57:06 +02:00
0006-search-defaults.md v131 2024-10-12 11:57:06 +02:00
0007-synchronized-releases.md v131 2024-10-12 11:57:06 +02:00
0008-tab-groups.md v131 2024-10-12 11:57:06 +02:00
0009-remove-interactors-and-controllers.md v131 2024-10-12 11:57:06 +02:00
0010-add-state-based-navigation.md v131 2024-10-12 11:57:06 +02:00
0011-decouple-home-activity-and-external-app-browser-activity.md v131 2024-10-12 11:57:06 +02:00
0012-introduce-ui-store.md v131 2024-10-12 11:57:06 +02:00
0013-rfc-process-updates.md v131 2024-10-12 11:57:06 +02:00
README.md v131 2024-10-12 11:57:06 +02:00

README.md

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. Substantial changes to public APIs in Android Components, like the changes found in 0003 Concept Base Component and 0008 Tab Groups.
  2. Changes to process that affect other teams, like the changes found in 0001 RFC Process, 0013 Add stakeholders to RFCs, and 0007 Synchronized Releases.
  3. Proposals for changes to areas of the codebase that are owned by CODEOWNERS outside the author's team.

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

  1. Announcing a rough plan for changes to a public API you own in order to solicit feedback.
  2. Soliciting feedback for architectural changes that affect the entire codebase, like 0009 Remove Interactors and Controllers.

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. Choose a deadline for general feedback.
  2. Select and communicate with stakeholders.
  3. Share the RFC more broadly through Slack and mailing lists for general feedback (like firefox-android-team@ and firefox-mobile@).
  4. Build consensus and integrate feedback.

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.