{% set rfcid = "RFC-0017" %} {% include "docs/contribute/governance/rfcs/_common/_rfc_header.md" %}
This RFC discontinues the FTP process, folds existing FTPs into RFCs, and amends the RFC process as follows:
- Encourage to use of a more dynamic medium than a code review during the socialization phase;
- Require the use of the RFC template, and include area specific portions in this RFC template;
- Formalize the existence of criteria per area;
- Have the Fuchsia Eng Council (FEC) play a more active role in identifying stakeholders;
- Add an FEC facilitated meeting to discuss an RFC, with specific triggers calling for meeting;
- Submission step at author(s) discretion, with a seven business days SLA for an authoritative answer from the FEC.
With the introduction of the RFC Process in February 2020, changes to FIDL which meet the FTP criteria would technically also require an RFC. In actuality, the various FTPs which were accepted or rejected since did not double up by also going through the RFC process: both processes aim for similar goals, and have similar level of formality, and review.
However, it is our desire to unify Fuchsia around a single review process for technical changes, and are therefore looking to discontinue the FTP process, in favor of the RFC process.
The FTP process has been a success for the two and a half years it ran, and we additionally look to bring some of the lessons learned to the RFC process.
We first survey differences between the FTP process and the RFC process, and then propose a set of amendments to the RFC process.
Lastly, we describe how to fold all FTPs into RFCs to further centralize all artifacts of Fuchsia technical decisions.
The FTP process does not mandate a medium, and author(s) are free to choose the medium they believe is best whilst adhering to the template imposed. In practice, all FTPs have started as Google Doc until their approval or rejection, at which point these documents were converted into a Markdown document, and committed to the Fuchsia source tree. Final edits and editorial polish were often done during conversion.
The RFC process mandates the use of a Gerrit change (a.k.a. a CL) as the medium, and asks that iterations be done by using subsequent patch sets of the change with stakeholders invited to be reviewers of the change.
It is the author's opinion that the ease of commenting on a Google Doc, suggesting an edit, or making changes is a catalyst for a healthy technical conversation. Multiple RFCs actually started in Google Doc themselves during their socialization phase, such that their draft was actually closer to a finalized document. When choosing another medium than Gerrit for socialization, care should be taken to avoid arbitrarily limiting the target audience. For instance, the Google Doc should be 'world accessible'.
The FTP process strictly requires the use of the FTP template, and asks for all sections to be filled in, even if only to explicitly state "not applicable".
In contrast, the RFC process recommends but does not mandate the use of the RFC template.
By nature of being designed specifically for FIDL, the FTP template asks probing questions which are specifically catering to this area. The FTP template has evolved over time, to address new requirements. For instance, a specific call out for source compatibility implications was added in RFC-0024: Mandatory Source Compatibility. This stricter format and specific questions has helped FTP authors and their reviewers ensure their design was complete.
Note: The FTP template was not publicly accessible prior to this change. This lack of public access was purely logistical. To date, contributors have been Googlers with @google.com e-mail addresses, the template lived in a Google Doc due to the ease of copying it to create a new FTP, a Google Doc cannot be shared openly per google.com domain policy, maintaining two copies (e.g. one in Markdown and one in a Google Doc) leads to content skew.
The FTP process most commonly reviews proposals during one or multiple in-person meetings. While using an asynchronous review mechanism, such as comments on a Gerrit change, is also possible it is the exception rather than the norm.
The RFC process encourages an asynchronous review mechanism, and author(s) are encouraged to schedule a meeting if the discussion is too complex.
An important distinction here is that the FTP review meeting is organized and scheduled by the Fuchsia FIDL team, whereas the RFC process asks author(s) to schedule the meeting. There is potentially an important information asymmetry between author(s) and those driving processes (the FIDL team, the Fuchsia Eng Council). Placing the responsibility of organizing review meetings with author(s) instead of those driving the processes introduces an additional hurdle, which may not be easy to overcome especially when it requires navigating the project organization and knowing who to invite.
The FTP process has specific criteria for when it should be used.
Similarly, the RFC process has specific criteria for when it should be used, and special considerations for Zircon were later added.
The FTP process relies on the Fuchsia FIDL team to make decisions, with the ultimate decision maker being the Fuchsia FIDL team lead.
The RFC process relies on relevant stakeholders voicing their approval or refusal, with the Fuchsia Eng Council (FEC) making the ultimate decision.
The two decision making approaches are similar, especially if you consider that the FIDL team would be a key stakeholder for all RFCs modifying FIDL. One important distinction is that the FTP process requires a "push model", where authors must submit their design to the FIDL team. The RFC process is more in the "pull model", it is the responsibility of the FIDL team to be proactive and engage with relevant designs in order to be heard.
The FTP process has a specific SLA to provide an authoritative answer ("five business days"). This was specifically added during the iteration phase on FTP-049 with someone commenting that "from the perspective of an FTP author, it'd be good to know when the FIDL team will be making a decision on an FTP".
The RFC process does not have an SLA today.
The FTP process assigns a sequential number when an FTP is started.
The RFC process assigns a sequential number when an RFC is accepted or rejected.
Medium The RFC process should offer the use of a more dynamic medium than a code review during the socialization phase, e.g. Google Doc or other. Arguably, this is not a change to the RFC process which only mandates the use of a Gerrit change for the formal part of the process, but acknowledging and encouraging another medium during the socialization phase of an RFC may clear confusion.
The RFC process should also strongly encourage relevant context from the more dynamic medium to be carried over to RFC writeup. For instance, back-and-forth conversations may lead to additional "alternatives considered" entries to be added.
Template The RFC process should require the use of a template. Each area may have relevant probing questions or sections that should be included for proposals in their respective area.
Template: FTP specific The RFC template should be augmented to include the specific content of the FTP template for use by RFCs touching the FIDL area.
RFC Criteria Each area is encouraged to submit additional criteria for when an RFC should be followed for their respective area. If criteria for an area exists, the FEC will ensure that appropriate stakeholders are looped in. Arguably, this is not a change to the RFC process since one can simply submit an RFC to amend the process, e.g. what was done for Zircon. However, by streamlining the existence of criteria for all areas, we believe that more areas will explicitly state what is "important" for them. In addition to ensuring these areas are appropriately looped in, it will have the additional benefit of documenting the relative importance of a change.
RFC Criteria: FTP specific The RFC process should include the criteria identified in FTP-049 for the FIDL area.
Stakeholders While RFC author(s) should do their best to identify stakeholders, the FEC should have an active role in determining the stakeholders as well. RFC author(s) should request from the FEC to identify all stakeholders early in the process, thus reducing the likelihood of a surprise at the submission step.
Eng review meeting At FEC's discretion, RFCs that would benefit from more socialization should be scheduled for an engineering review meeting. Some triggers leading to scheduling an engineering review are:
- Difficulty to identify relevant stakeholders(s). It might be the case than an RFC receives many comments, suggestions, push back, and that the author(s) are unclear how to act on this feedback, and which represents core feedback which is potentially a blocker to the RFC being accepted, vs auxiliary feedback which may be curiosity, future plans, etc.
- Difficulty for RFC author(s) and stakeholder(s) to converge on open items.
Submitting Rather than gating submission of an RFC on conversations converging — which may be hard for author(s) to identify in certain cases - the RFC process should instead permit author(s) to request a review to be done by the FEC. When such a request is made, the FEC has seven (7) business days to answer authoritatively to the author(s). The answer is either:
- Approval, or
- Rejection, or
- Unresolved open items: FEC identifies one or many unresolved open items, and asks the author(s) to resolve them with relevant stakeholders before another request to review the RFC will be granted.
Mechanically, to fold FTPs into RFCs we will:
-
Re-number all FTPs to sequential numbering, following existing RFCs. For instance, as of this writing, FTP-001 would become RFC-0017.
-
Update each FTP writeup to display its RFC number as the main title, while also keeping a trace of its former FTP number. Keeping a record of the old numbering is important because many git commits or bugs reference FTPs by number.
-
For reference reason, we will want to keep a trace of the existence of the FTP process (e.g. many links in this RFC).
-
Going forward, FTPs which have now been converted to RFCs should be referenced by RFC number (and not by their historical FTP number).
Keep calm, and follow the process.
This proposal is expected to have a positive impact on performance, security, privacy, and testing considerations.
We need to update:
- All FTPs.
- All references to FTPs, both in Markdown and in code comments.
- The FIDL governance section.
- The RFC process summary page.
Keeping two formal processes which are roughly equivalent in the same technical project introduces confusion. We do not consider leaving things as is to be an alternative.
Each amendment to the RFC process proposed above can be evaluated in and of itself. We believe that these are all changes which provide a net benefit.
This RFC consolidates the RFC Process with the FTP Process i.e. FTP-001: A Modest Proposal and FTP-049: FIDL Tuning Process Evolution.