{"id":19608637,"url":"https://github.com/sel4/rfcs","last_synced_at":"2026-06-17T07:32:22.292Z","repository":{"id":244722579,"uuid":"813557977","full_name":"seL4/rfcs","owner":"seL4","description":"RFCs for the seL4 ecosystem","archived":false,"fork":false,"pushed_at":"2025-12-15T04:39:36.000Z","size":126,"stargazers_count":0,"open_issues_count":9,"forks_count":7,"subscribers_count":19,"default_branch":"main","last_synced_at":"2025-12-17T23:32:16.308Z","etag":null,"topics":["sel4"],"latest_commit_sha":null,"homepage":"https://sel4.github.io/rfcs/","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/seL4.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":".github/CONTRIBUTING.md","funding":null,"license":"LICENSE.md","code_of_conduct":".github/CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2024-06-11T09:56:44.000Z","updated_at":"2025-12-15T04:39:40.000Z","dependencies_parsed_at":"2025-01-09T09:49:00.621Z","dependency_job_id":"b136f66e-a8fc-4efb-ae5f-7ef53f2941b7","html_url":"https://github.com/seL4/rfcs","commit_stats":null,"previous_names":["sel4/rfcs"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/seL4/rfcs","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/seL4%2Frfcs","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/seL4%2Frfcs/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/seL4%2Frfcs/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/seL4%2Frfcs/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/seL4","download_url":"https://codeload.github.com/seL4/rfcs/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/seL4%2Frfcs/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":34439296,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-17T02:00:05.408Z","response_time":127,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["sel4"],"created_at":"2024-11-11T10:16:05.394Z","updated_at":"2026-06-17T07:32:22.278Z","avatar_url":"https://github.com/seL4.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"\u003c!--\n  SPDX-License-Identifier: CC-BY-SA-4.0\n  Copyright 2020 seL4 Project a Series of LF Projects, LLC.\n--\u003e\n\n# seL4 Request for Comments (RFC) Process\n\n\u003e - [Approved RFCs](https://sel4.github.io/rfcs/)\n\u003e - [Open RFCs](https://github.com/seL4/rfcs/pulls?q=is%3Aopen+is%3Apr+-label%3Anot-rfc+)\n\u003e - [RFCs under implementation](https://github.com/seL4/rfcs/tree/main/src/active)\n\nTo be notified of new RFCs, use the GitHub button on the top to watch pull\nrequests on this repository.\n\nThe seL4 foundation uses the request for comments (RFC) process to\n\n- allow the community to discuss design changes in seL4,\n- gather valuable feedback from the community on changes the foundation is\n  considering,\n- allow members of the seL4 community to get support and approval to propose and\n  implement their own changes to the seL4 ecosystem,\n- ensure that all changes made to core components of the seL4 ecosystem or that\n  have wide and varying impacts on users of seL4 undergo rigorous review, and\n- ensure large changes are well advertised and can viewed publicly before\n  contributors commit to implementing them.\n\nThis helps the seL4 community ensure that such changes are made with the goal of\nthe best outcome for the most users of seL4 without compromising seL4's\nhigh-assurance properties of functional correctness, isolation, and security.\n\n- [When to follow the RFC process](#when-to-follow-the-rfc-process)\n- [When not to follow the RFC process](#when-not-to-follow-the-rfc-process)\n- [The RFC Process](#the-rfc-process)\n  - [Before creating a new RFC](#before-creating-a-new-rfc)\n  - [Proposing an new RFC](#proposing-an-new-rfc)\n  - [Getting an RFC approved](#getting-an-rfc-approved)\n  - [Postponement of an RFC](#postponement-of-an-rfc)\n  - [Stage 1 approval](#stage-1-approval)\n  - [Implementation of an approved RFC](#implementation-of-an-approved-rfc)\n  - [Deferment of an approved RFC](#deferment-of-an-approved-rfc)\n- [RFC states](#rfc-states)\n  - [Under discussion](#under-discussion)\n  - [Ready for implementation](#ready-for-implementation)\n  - [Closed](#closed)\n\n## When to follow the RFC process\n\nAll substantial changes to the seL4 ecosystem must be made using the RFC\nprocess. Substantial changes are those that that impact a large number of users\nof seL4 in a way that may require them to change their own projects, changes the\noperation of toolchain used to build projects on seL4, changes the underlying\nmodel of one or more software components within the ecosystem.\n\nExamples of changes that must follow the RFC process include:\n\n- Removing support for a platform\n- Adding support for a new architecutre to the kernel\n- Changing the versioning system used for libraries\n- Adding a new API feature to the kernel\n- Adding a new operation/invocation to an existing capability type, or removing one\n- Adding or removing a capability or object type\n- Adding or removing a library or framework to/from the set of repositories the\n  foundation maintains\n\nIf you try to make a substantial change via a pull request alone, your request\nis likely to be rejected and you will be asked to use the RFC process to propose\nyour change instead. It is Ok to make draft pull request in conjunction with an\nRFC or link to an implementation in another repository if you want to provide a\nprototype implementation for helping the RFC discussion. In that case, please\nindicate so in the pull request and provides links in RFC and PR.\n\n## When not to follow the RFC process\n\nChanges such as bug fixes, refactoring, optimisations, or those that do not\naffect the functional requirements of the kernel, supporting tooling,\ninfrastructure, or system components can be made through the existing pull\nrequest process on the relevant repository.\n\nExamples of changes that should not involve the RFC process include:\n\n- Fixing a typo in existing code,\n- Clarifying code or documentation,\n- Adding a driver to an existing layer of the system\n- Refactoring code without affecting functionality or verification\n\nIf you are unsure whether a change requires an RFC, ask on the [seL4 Mattermost]\nchat or post a question to the [development mailing list] or [discourse forum].\n\n\n## The RFC Process\n\n### Before creating a new RFC\n\nBefore proposing a new RFC it is important to determine whether it will be\nsupported and what possible options exist to solve the particular problem.\n\nThis should be done through discussion on one of seL4 [community forums].\nPosting a partial pre-RFC write-up on the [RFC discourse forum] can be\na good way to get the discussion started and get people interested in your idea.\n\nThis part of the process should help you determine whether your idea has already\nbeen proposed, whether or not it fits with the near-term goals of the ecosystem,\nand how to propose it with the best chances of acceptance.\n\nYou should make sure that during this discussion you address as many of the\nsections in the RFC [template] as you can. This will ensure that your proposal is\nwell prepared before it is formally presented as an RFC and will speed up much\nof the RFC process.\n\nOnce you have the support of some existing seL4 developers they can help you\ntake your idea through the rest of the RFC process.\n\nAfter discussion, RFCs will ultimately be approved, postponed, or rejected by\na decision of the [Technical Steering Committee][TSC] of the seL4 Foundation.\n\n[seL4 Mattermost]: https://mattermost.trustworthy.systems/sel4-external/ \"seL4 Mattermost\"\n[development mailing list]: https://lists.sel4.systems/postorius/lists/devel.sel4.systems/ \"seL4 development mailing list\"\n[discourse forum]: https://sel4.discourse.group \"seL4 discourse forum\"\n[RFC discourse forum]: https://sel4.discourse.group/c/rfc-discussion/\n[community forums]: https://sel4.systems/contact/\n[TSC]: https://sel4.systems/Foundation/TSC/ \"seL4 Technical Steering Committee\"\n[template]: 0000-template.md \"RFC template\"\n\n\n### Proposing an new RFC\n\nAn RFC exists in the form of a pull request on the seL4 [RFC repository]. Anyone\ncan propose an RFC.\n\nYou should check the [postponed RFCs] to see if your idea has already been\nproposed but was previously postponed. You can adopt a postponed RFC which will\nreturn it to the proposal stage and you will become responsible for it.\n\nOnce you create an RFC, you are the one responsible for maintaining it\nthroughout the approval process and making sure it makes progress. You will be\nable to modify it in response to discussion and feedback up until the point it\nis either approved or rejected.\n\nEvery RFC should use the RFC [template], omitting sections that are not relevant\nfor the RFC (most sections will be relevant, do not omit them lightly).\n\n[RFC repository]: https://github.com/seL4/rfcs \"seL4 RFC repository\"\n[postponed RFCs]: https://github.com/seL4/rfcs/pulls?q=is%3Aclosed+is%3Apr+label%3Apostponed\n\n\n### Getting an RFC approved\n\nAfter you propose an RFC, it is likely to undergo several rounds of changes in\nresponse to the discussion on the pull request. Anyone is allowed to engage in\nthis discussion.\n\nOnce the discussion phase is concluded, for instance because consensus has been\nreached or it has become clear that there will not be a consensus, the\n[Technical Steering Committee][TSC] of the seL4 Foundation will make a decision\non the RFC, usually in an online video meeting, sometimes via email.\n\nThe Steering Committee will either give stage 1 approval, fully approve,\npostpone, defer, require changes, or reject the RFC. When this occurs, a\n_disposition_ will be added to the RFC outlining the reason for the particular\nruling. If the discussion of an RFC has been particularly long, a summary\ncomment will be made on the RFC before the given ruling is made.\n\n\n### Postponement of an RFC\n\nWhen an RFC has a moderate amount of support and is generally accepted as a good\nidea but lacks someone to shepherd it to the point where it can be accepted it\nis _postponed_.\n\nThis indicates that the RFC may be revived in the future when someone can be\nfound to take it through the remainder of the approval process. Anyone may\n_adopt_ a postponed RFC if they wish to see it approved and want to rally\nsupport for it.\n\n[Postponed RFCs] are pull requests that are closed with the postponed label.\nReopening the pull request means you wish to adopt it, restart discussion, and\ndevelop it further.\n\n### Stage 1 approval\n\nIn some cases, an RFC may require an implementation or very detailed design to\nproperly judge its merits. When the TSC decides that an RFC is likely to get\naccepted if a convincing implementation can be shown, the TSC may give _stage 1\napproval_ for this RFC. Stage 1 approval means a candidate implementation should\ngo ahead, but will need to be reviewed again, e.g. for performance and\nusability, before it can be fully accepted.\n\nRFCs with stage 1 approval are open pull requests with the stage 1 approval\nlabel.\n\n### Implementation of an approved RFC\n\nOnce the Steering Committee approves an RFC, the corresponding pull request is\nmerged and the RFC marked as _active_. The TSC may assign it to a contributor\nfor implementation (e.g. the RFC proposer), may create an issue for tracking\nimplementation, or continue more detailed implementation discussion on a\ncorresponding draft pull request if that already exists.\n\nThe implementation of an RFC may lead to the resolution of many issues that were\npresent in the RFC when it was approved. As such, the RFC may be subject to\nfurther changes throughout this part of the process. These changes should not\nchange the overall goals or design of the RFC but should merely resolve issues\nor extend the design to cope with unanticipated corner cases. They should be\nreflected in the RFC text via additional pull requests to the [RFC repository].\n\nWhen implementation is complete, the RFC is marked as _implemented_.\n\n### Deferment of an approved RFC\n\nThere may not be sufficient resources to implement an RFC when it is approved or\nresources may be diverted from the implementation of an RFC when higher priority\nwork arises. In either case, the RFC will be _deferred_. A _deferred_ RFC is\nlower priority than an _active_ one and will generally see no progress on its\nimplementation.\n\nAnyone can request that a _deferred_ RFC be given priority be demonstrating\nincreased demand or urgency for its implementation, volunteering to work on the\nimplementation, or find funding for the Foundation to implement it.\n\n## RFC states\n\nIn summary, an sel4 RFC can be in the following states:\n\n### Under discussion\n\n- **open:** a new RFC, open pull request with ongoing discussion\n- **stage 1 approved:** likely enough to be accepted for detailed design, open\n  pull request with label _stage 1 approval_.\n\n### Ready for implementation\n\n- **approved:** approved for implementation, merged RFC pull request, marked as active,\n  should have tracking issue or draft implementation PR with an assignee\n- **deferred:** approved for implementation, but not currently being worked on,\n  merged RFC pull request, marked as deferred\n\n### Closed\n\n- **implemented:** work on this RFC is finished, closed RFC PR and implementation,\n  marked as implemented\n- **postponed:** closed RFC pull request, can be reopened, labelled as postponed\n- **rejected:** closed RFC pull request, labelled as rejected\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsel4%2Frfcs","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsel4%2Frfcs","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsel4%2Frfcs/lists"}