tree: 505fc21f3cba53138175c7697c4bf4edf6ef5fed [path history] [tgz]
  1. 0001_rfc_process.md
  2. 0002_platform_versioning.md
  3. 0003_logging.md
  4. 0004_units_of_bytes.md
  5. 0005_blobfs_snapshots.md
  6. 0005_blobfs_snapshots_fig_1.png
  7. 0005_blobfs_snapshots_fig_2.png
  8. 0005_blobfs_snapshots_fig_3.png
  9. 0005_blobfs_snapshots_fig_4.png
  10. 0006_addendum_to_rfc_process_for_zircon.md
  11. 0007_remove_thread_killing.md
  12. 0008_remove_zx_clock_get_and_adjust.md
  13. 0009_edge_triggered_async_wait.md
  14. 0010_channel_iovec.md
  15. 0011_getinfo_kmemstats_extended.md
  16. 0012_zircon_discardable_memory.md
  17. 0014_relax_fifo_create_constraints.md
  18. 0015_cts.md
  19. 0016_boot_time_page_sizes.md
  20. OWNERS
  21. README.md
  22. TEMPLATE.md
  23. _areas.yaml
  24. _common/
  25. _eng_council.yaml
  26. _rfcs.yaml
  27. _toc.yaml
  28. create_rfc.md
  29. current_rfc_process.md
docs/contribute/governance/rfcs/README.md

{% include “docs/contribute/governance/rfcs/_common/_rfc_header.md” %}

Fuchsia RFCs

The Fuchsia RFC process is intended to provide a consistent and transparent path for making project-wide, technical decisions. For example, the RFC process can be used to evolve the project roadmap and the system architecture.

The RFC process evolves over time, and can be read here in its [detailed current form] (current_rfc_process.md). It is also summarized below.

Summary of the process

  • Review criteria for requiring an RFC.
  • Socialize your idea.
  • Draft your RFC using this template.
  • Iterate your idea with appropriate stakeholders.
  • After stakeholders signoff, email eng-council@fuchsia.dev to prompt the Eng Council to decide whether to accept your RFC.
  • If your RFC is accepted, a member of the Eng Council will comment on your change stating that the RFC is accepted, will assign the RFC a number and mark your change Code-Review +2. Your RFC can now be landed.

Criteria for requiring an RFC

Criteria for requiring an RFC is detailed in RFC-0001.

The following kinds of changes must use the RFC process.

  • Changing the project roadmap
  • Adding constraints on future development
  • Making project policy
  • Changing the system architecture
  • Delegating decision-making authority
  • Escalations

In addition, changes in the source directories:

  • /zircon
  • /src/zircon
  • /src/bringup

that meet the following criteria must use the RFC process as described in RFC0006: Addendum of the RFC Process for Zircon.

  • Adding or removing Zircon system interfaces.
  • Changing resource handling behaviors.
  • Modifying isolation guarantees.
  • Significant changes of performance or memory use.
  • Favoring a single platform.
  • Adding or Downgrading support for a platform.
  • New build configurations.

Process to submit an RFC

Once you are familiarized with the RFC guidelines and area ready to send an RFC proposal for review, see Creating a RFC.

Proposals

Active RFCs

Gerrit link

Finalized RFCs

Accepted {% include “docs/contribute/governance/rfcs/_common/_index_table_header.md” %} {% for rfc in rfcs %} {% if rfc.status == “Accepted” %} {% include “docs/contribute/governance/rfcs/_common/_index_table_body.md” %} {% endif %} {% endfor %} {% include “docs/contribute/governance/rfcs/_common/_index_table_footer.md” %}

Rejected {% include “docs/contribute/governance/rfcs/_common/_index_table_header.md” %} {% for rfc in rfcs %} {% if rfc.status == “Rejected” %} {% include “docs/contribute/governance/rfcs/_common/_index_table_body.md” %} {% endif %} {% endfor %} {% include “docs/contribute/governance/rfcs/_common/_index_table_footer.md” %}

{# This div is used to close the filter that is initialized above #}