Overview
The Fuchsia Engineering Council (FEC) is a small group of senior technical leaders responsible for providing a coherent technical vision for Fuchsia. The council largely operates by delegation and ratification, promulgating engineering standards, values, and objectives throughout the community and then reviewing and ratifying concrete engineering proposals from project contributors. Concretely, the FEC is charged with approving or rejecting Fuchsia RFCs using the Fuchsia RFC Process and resolving technical disputes that cannot be resolved within subteams.
How to Contact
Members of the FEC can be reached by emailing eng-council@fuchsia.dev. Public discussions involving FEC should use the eng-council-discuss@fuchsia.dev list.
Goals
The goal of the FEC is to drive technical excellence in the Fuchsia platform by providing a coherent technical vision for the project.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. — Melvin E. Conway
By being a top-level node in the communication structure of the project, the council helps produce a system design that makes coherent, project-wide trade-offs.
In making trade-offs, the council aims to uphold the project’s values:
Respect the user. The council gives the most weight to factors that impact the end-user of products built using Fuchsia. For example, the council prefers designs that improve the security, privacy, and performance of the system because those aspects of the system directly benefit end-users.
Respect the developer. The council gives more weight to factors that impact end-developers, who write software that runs on Fuchsia, than to factors that impact project contributors, who write software that is part of Fuchsia itself. For example, breaking interface contracts might be convenient for project contributors but such changes impose costs on end-developers that must be weighed heavily.
Be pragmatic. The council prefers approaches that work well in practice over approaches that are perfect in theory. For example, the council favors designs that have been proven out by running code over designs that exist only on paper.
Activities
The council is responsible for the following activities. The bulk of these activities occur in public, but the council can communicate privately if the council needs to consider non-public information.
System architecture
The council maintains a set of documents that describe the system architecture. These documents are descriptive of the current state of the system rather than prescriptive about how the system architecture should evolve. Prescriptive proposals for changing the system architecture should instead be published using the Fuchsia RFC Process.
The system architecture documents drive technical coherence throughout the system because they help contributors understand how the system works overall and how their part of the system fits into the whole.
Engineering standards
The council maintains documentation about the engineering standards for the project. The engineering standards describe the engineering values the project applies when reviewing code contributions and design documents. For example, the standards describe the level of testing expected for code contributions and the balance between short- and long-term considerations in designs.
The council may delegate part of this responsibility. For example, it oversees the API Council, which is responsible for Fuchsia’s API surface.
Engineering review
The council facilitates engineering design reviews. The council establishes the norm that engineering design documents should be published as RFCs, including supporting RFC authors in socializing their designs and in identifying appropriate stakeholders to review the designs in detail.
Request for comments (RFCs)
The most common way to review engineering designs will be through the Fuchsia RFC Process. In this process, the council makes the formal decision about whether the project accepts or rejects an RFC. The council’s role in this process is largely to ensure that an RFC has received a Code-Review +2 from an appropriate set of stakeholders, who are responsible for reviewing the document in detail.
If there is a technical dispute that cannot be resolved between the RFC author and one or more stakeholders, the council can resolve the dispute by accepting or rejecting the RFC. If there is a technical dispute that arises in the course of the project, the council can ask one of the disputants to record the resolution of the dispute in an RFC.
Eng Reviews
The council can also review engineering designs in an Eng Review meeting. The council prefers to use the RFC process when possible because the RFC process allows for broader participation in the review. However, Eng Reviews can be appropriate when the issue is time-sensitive, involves confidential information, or when the discussion is too complex for a code review thread.
The council’s role in an Eng Review is largely to facilitate the discussion and make a formal decision about the resolution of the issue being reviewed. The non-confidential outcome of an Eng Review should be published in an RFC.
Dispute resolution
The council is responsible for resolving technical disputes that cannot be resolved within individual teams. Disputes can be escalated to the council by people either directly or indirectly involved in the dispute. The council prefers to resolve disputes by mediation, but the council is empowered to arbitrate disputes that cannot be resolved through mediation.
Decision process
The council makes formal decisions by rough consensus among council members, as assessed by the chair. If the council cannot come to rough consensus, the chair will make the final decision.
Membership
There is no predetermined number of people on the council. However, in order to provide a coherent technical vision, the council has a small number of members. Members are appointed by the governing authority for the project.
Qualifications
Members are expected to meet the following criteria:
Members must be deeply knowledgeable about Fuchsia. Typically, contributors acquire this knowledge by working on the project for a substantial amount of time and by interacting with multiple parts of the system.
Members must be widely respected by the Fuchsia community. Although the council does have some formal decision-making authority, council members largely drive technical excellence indirectly through influence, which works best when members are widely respected in the community.
Members must have strong conflict-resolution skills. One important function of the council is to resolve technical disputes, which requires council members to exhibit strong conflict resolution skills, which often involves strong communication skills.
Members must also have a demonstrated track record of technical leadership. For example, a member might be the de facto or formal authority for a significant component of Fuchsia or might be someone whose expertise and judgment is sought after for evaluating proposed changes to the system.
Whether a candidate meets the criteria above is to be determined by the appointing body. Council members need not be employed by any specific company or organization.
Current members
The current members of the Fuchsia Eng Council are listed in this OWNERS file.