2017-11-09 22:41:53 +00:00
# TUF governance
This document covers the project's governance and committer process. The
project consists of the TUF
[specification ](https://github.com/theupdateframework/specification ) and
2021-09-01 10:14:55 +00:00
[reference implementation ](https://github.com/theupdateframework/python-tuf ).
2017-11-09 22:41:53 +00:00
2017-11-13 16:03:44 +00:00
## Maintainership and Consensus Builder
2017-11-13 15:43:18 +00:00
The project is maintained by the people indicated in
2018-01-24 19:09:48 +00:00
[MAINTAINERS ](MAINTAINERS.txt ). A maintainer is expected to (1) submit and
2017-11-13 15:43:18 +00:00
review GitHub pull requests and (2) open issues or [submit vulnerability
2021-09-01 10:14:55 +00:00
reports](https://github.com/theupdateframework/python-tuf#security-issues-and-bugs).
2017-11-09 22:41:53 +00:00
A maintainer has the authority to approve or reject pull requests submitted by
2022-01-13 16:55:30 +00:00
contributors.
2019-11-05 14:00:35 +00:00
More significant changes in the project, such as those that require a TAP or
2022-01-13 16:55:30 +00:00
changes in governance, are guided by a maintainer called the Consensus
Builder (CB). The project's Consensus Builder (CB) is Justin Cappos
2019-11-09 17:33:48 +00:00
< jcappos @ nyu . edu , @JustinCappos > , who has a lifetime appointment.
2017-11-09 22:41:53 +00:00
## Contributions
[A contributor can submit GitHub pull
2022-02-09 14:00:42 +00:00
requests](CONTRIBUTING.rst)
2017-11-13 15:43:18 +00:00
to the project's repositories. They must follow the project's [code of
conduct](CODE-OF-CONDUCT.md), the [developer certificate of
origin](https://developercertificate.org/), the [code style
guidelines](https://github.com/secure-systems-lab/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:
2017-11-09 22:41:53 +00:00
2021-09-01 10:14:55 +00:00
* Unit and build testing via [GitHub Actions ](https://github.com/theupdateframework/python-tuf/actions ) and
2017-11-29 20:01:21 +00:00
[Tox ](https://tox.readthedocs.io/en/latest/ ).
* Static code analysis via [Pylint ](https://www.pylint.org/ ) and
[Bandit ](https://wiki.openstack.org/wiki/Security/Projects/Bandit ).
Require black and isort in tuf/api/* via tox
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>
2021-03-11 17:03:08 +00:00
- Auto-formatting with [black ](https://black.readthedocs.io/ ) and
[isort ](https://pycqa.github.io/isort/ ).
2017-11-29 20:01:21 +00:00
* Checks for Signed-off-by commits via [Probot: DCO ](https://github.com/probot/dco ).
* Review by one or more
2018-01-24 19:09:48 +00:00
[maintainers ](MAINTAINERS.txt ).
2017-11-09 22:41:53 +00:00
A contributor can propose changes to the specification with a [TUF Augmentation
Proposal](https://github.com/theupdateframework/taps) (TAP). It is a design
document providing information to the TUF community, or describing a new
2017-11-13 15:43:18 +00:00
feature for TUF or its processes or environment.
2018-01-24 19:09:48 +00:00
A [TAP ](TAP.rst ) can be approved or rejected by the CB after it has been reviewed and
2017-11-13 15:43:18 +00:00
discussed. Discussions take place on the project's [mailing
list](https://groups.google.com/forum/?fromgroups#!forum/theupdateframework) or
the TAPs GitHub issue tracker.
2017-11-09 22:41:53 +00:00
## Changes in maintainership
A contributor to the project must express interest in becoming a maintainer.
2017-11-13 16:02:26 +00:00
The CB has the authority to add or remove maintainers.
2017-11-09 22:41:53 +00:00
## Changes in governance
2019-10-30 10:31:33 +00:00
2022-01-13 16:55:30 +00:00
The CB supervises changes in governance, but a majority of maintainers must vote +1 on the PR.
2019-11-09 17:33:48 +00:00
## 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.
2019-10-30 10:31:33 +00:00
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 ](MAINTAINERS.txt ) 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.
