5a626ca4b4
Configure lint build in tox.ini to check if code in tuf/api/* is formatted according to black and isort style rules: https://black.readthedocs.io/en/stable/the_black_code_style.html https://pycqa.github.io/isort/ In addition to our new style guide (#1128) and corresponding linter configuration, requiring auto-formatting should help to further reduce reviewing effort. The auto-formatter black was chosen for the following reasons: - It seems to be the most popular formatter in the Python ecosystem - It is well documented including integration instructions with most of the tools we use (git, GitHub Actions, pylint, a range of editors, pyproject.toml #1161) - It checks that the reformatted code produces a valid AST that is equivalent to the original - It has almost no ways of customization, which means no customization effort required, and more (cross-project) style uniformity, lowering contribution barriers - It converts single to double quotes, where reasonable, which is exactly what we recommend - The style choices it makes seem generally reasonable and don't conflict with our style guide, except for favoring hanging over aligned indentation, which is the opposite of what we recommend. But we are willing to update the adapt our style guide. Auto-format pre-commit configuration will be added in a subsequent commit. Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
3.7 KiB
TUF governance
This document covers the project's governance and committer process. The project consists of the TUF specification and reference implementation.
Maintainership and Consensus Builder
The project is maintained by the people indicated in MAINTAINERS. A maintainer is expected to (1) submit and review GitHub pull requests and (2) open issues or submit vulnerability reports. A maintainer has the authority to approve or reject pull requests submitted by contributors.
More significant changes in the project, such as those that require a TAP or changes in governance, are guided by a maintainer called the Consensus Builder (CB). The project's Consensus Builder (CB) is Justin Cappos <jcappos@nyu.edu, @JustinCappos>, who has a lifetime appointment.
Contributions
A contributor can submit GitHub pull requests to the project's repositories. They must follow the project's code of conduct, the developer certificate of origin, the code style guidelines, and must unit test any new software feature or change. Submitted pull requests undergo review and automated testing, including, but not limited to:
- Unit and build testing via GitHub Actions and Tox.
- Static code analysis via Pylint and Bandit.
- Checks for Signed-off-by commits via Probot: DCO.
- Review by one or more maintainers.
A contributor can propose changes to the specification with a TUF Augmentation Proposal (TAP). It is a design document providing information to the TUF community, or describing a new feature for TUF or its processes or environment.
A TAP can be approved or rejected by the CB after it has been reviewed and discussed. Discussions take place on the project's mailing list or the TAPs GitHub issue tracker.
Changes in maintainership
A contributor to the project must express interest in becoming a maintainer. The CB has the authority to add or remove maintainers.
Changes in governance
The CB supervises changes in governance, but a majority of maintainers must vote +1 on the PR.
Changes in the consensus builder
The consensus builder may be appointed for a fixed term or it may be a lifetime appointment. To initiate a change of consensus builder, or a change in the length of the appointment, a GitHub PR must be opened. If a fixed term is specified, the PR should be opened no earlier than 6 weeks before the end of the CB's term. If there is not a fixed term appointment, the PR may be opened at any time. In either case, the PR must be kept open for no less than 4 weeks. Additionally, the PR can only be merged with more +1 than -1 in the binding votes.
Anyone from the community can vote on the PR with either +1 or -1.
Only votes from maintainers that have been listed in the top-level MAINTAINERS file before the PR is opened are binding.
When there are conflicting PRs about changes in the consensus builder, the PR with the most binding +1 votes is merged.
The consensus builder can volunteer to step down.