You can see all of the repositories associated with L3AF by navigating to the top-level L3AF organization on GitHub.
Typically a L3AF project is represented by a single repository (repo). For instance, the Specs and Architecture project is represented in the l3af-arch repo. In the future it's possible that a single project may require multiple repos. The contents of this document still hold true in that case (and if you find that's wrong, please open an issue and we'll fix it).
The maintainers for each L3AF project are contained in the CODEOWNERS
file in the respective repositor(y|ies).
Maintainers listed in the CODEOWNERS
file for the purpose of this document are considered synonymous with committers.
There are many reasons why a maintainer may need to leave a project. In the case that one does, please follow these steps:
- Open an issue in the appropriate repo(s) describing the necessary change
- Create a pull request (PR) in each relevant repo, making the necessary change to the
CODEOWNERS
file - Add an item about the maintainer change to the agenda for the next L3AF TSC meeting
- Discuss the change in the meeting
- If the TSC approves (by majority vote of all present TSC members or their proxies), merge the PR. If they do not approve, close the PR without merging or continue the discussion with the TSC as necessary.
NO MAINTAINER CHANGES ARE VALID WITHOUT TSC APPROVAL
All projects should ideally have multiple maintainers (as listed in the relevant CODEOWNERS
file(s)).
There currently are no upper limits set on the number of maintainers for a L3AF project.
A project will have as many maintainers as it sees are useful for the functioning of the project and its community.
To add a maintainer to a L3AF project, please follow these steps:
- Open an issue in the appropriate repo(s) describing the necessary change
- Create a pull request (PR) in each relevant repo, making the necessary change to the
CODEOWNERS
file - Add an item about the maintainer change to the agenda for the next L3AF TSC meeting
- Discuss the change in the meeting
- If the TSC approves (by majority vote of all present TSC members or their proxies), merge the PR. If they do not approve, close the PR without merging or continue the discussion with the TSC as necessary.
NO MAINTAINER CHANGES ARE VALID WITHOUT TSC APPROVAL
(yes, this currently is exactly the same as removing a maintainer; we're documenting it separately to disambiguate the process for each and also to prepare for the eventuality that the processes will need to diverge)