|
| 1 | +# Community governance and review process |
| 2 | + |
| 3 | +This document describes maintainer expectations, project governance, and the detailed pull request review workflow (labels, merge queue, commit message format for mergers). For what contributors should do when opening and updating a PR, see [CONTRIBUTING.md](../CONTRIBUTING.md). |
| 4 | + |
| 5 | +## Code review |
| 6 | + |
| 7 | +### Milestone |
| 8 | + |
| 9 | +A PR should only be assigned to a milestone if it will likely be merged into the given version. \ |
| 10 | +PRs without a milestone may not be merged. |
| 11 | + |
| 12 | +### Labels |
| 13 | + |
| 14 | +Almost all labels used inside Gitea can be classified as one of the following: |
| 15 | + |
| 16 | +- `modifies/…`: Determines which parts of the codebase are affected. These labels will be set through the CI. |
| 17 | +- `topic/…`: Determines the conceptual component of Gitea that is affected, i.e. issues, projects, or authentication. At best, PRs should only target one component but there might be overlap. Must be set manually. |
| 18 | +- `type/…`: Determines the type of an issue or PR (feature, refactoring, docs, bug, …). If GitHub supported scoped labels, these labels would be exclusive, so you should set **exactly** one, not more or less (every PR should fall into one of the provided categories, and only one). |
| 19 | +- `issue/…` / `lgtm/…`: Labels that are specific to issues or PRs respectively and that are only necessary in a given context, i.e. `issue/not-a-bug` or `lgtm/need 2` |
| 20 | + |
| 21 | +Every PR should be labeled correctly with every label that applies. |
| 22 | + |
| 23 | +There are also some labels that will be managed automatically.\ |
| 24 | +In particular, these are |
| 25 | + |
| 26 | +- the amount of pending required approvals |
| 27 | +- has all `backport`s or needs a manual backport |
| 28 | + |
| 29 | +### Reviewing PRs |
| 30 | + |
| 31 | +Maintainers are encouraged to review pull requests in areas where they have expertise or particular interest. |
| 32 | + |
| 33 | +#### For reviewers |
| 34 | + |
| 35 | +- **Verification**: Verify that the PR accurately reflects the changes, and verify that the tests and documentation are complete and aligned with the implementation. |
| 36 | +- **Actionable feedback**: Say what should change and why, and distinguish required changes from optional suggestions. |
| 37 | +- **Feedback**: Focus feedback on the issue itself and avoid comments about the contributor's abilities. |
| 38 | +- **Request changes**: If you request changes (i.e., block a PR), give a clear rationale and, whenever possible, a concrete path to resolution. |
| 39 | +- **Approval**: Only approve a PR when you are fully satisfied with its current state - "rubber-stamp" approvals need to be highlighted as such. |
| 40 | + |
| 41 | +### Getting PRs merged |
| 42 | + |
| 43 | +Changes to Gitea must be reviewed before they are accepted, including changes from owners and maintainers. The exception is critical bugs that prevent Gitea from compiling or starting. |
| 44 | + |
| 45 | +We require two maintainer approvals for every PR. When that is satisfied, your PR gets the `lgtm/done` label. After that, you mainly fix merge conflicts and respond to or implement maintainer requests; maintainers drive getting the PR merged. |
| 46 | + |
| 47 | +If a PR has `lgtm/done`, no open discussions, and no merge conflicts, any maintainer may add `reviewed/wait-merge`. That puts the PR in the merge queue. PRs are merged from the queue in the order of this list: |
| 48 | + |
| 49 | +<https://github.com/go-gitea/gitea/pulls?q=is%3Apr+label%3Areviewed%2Fwait-merge+sort%3Acreated-asc+is%3Aopen> |
| 50 | + |
| 51 | +Gitea uses its own tool, <https://github.com/GiteaBot/gitea-backporter>, to automate parts of the review process. The backporter: |
| 52 | + |
| 53 | +- Creates a backport PR when needed after the initial PR merges. |
| 54 | +- Removes the PR from the merge queue after it merges. |
| 55 | +- Keeps the oldest branch in the merge queue up to date with merges. |
| 56 | + |
| 57 | +### Final call |
| 58 | + |
| 59 | +If a PR has been ignored for more than 7 days with no comments or reviews, and the author or any maintainer believes it will not survive a long wait (such as a refactoring PR), they can send "final call" to the TOC by mentioning them in a comment. |
| 60 | + |
| 61 | +After another 7 days, if there is still zero approval, this is considered a polite refusal, and the PR will be closed to avoid wasting further time. Therefore, the "final call" has a cost, and should be used cautiously. |
| 62 | + |
| 63 | +However, if there are no objections from maintainers, the PR can be merged with only one approval from the TOC (not the author). |
| 64 | + |
| 65 | +### Commit messages |
| 66 | + |
| 67 | +Mergers are required to rewrite the PR title and the first comment (the summary) when necessary so the squash commit message is clear. |
| 68 | + |
| 69 | +The final commit message should not hedge: replace phrases like `hopefully, <x> won't happen anymore` with definite wording. |
| 70 | + |
| 71 | +#### PR Co-authors |
| 72 | + |
| 73 | +A person counts as a PR co-author once they (co-)authored a commit that is not simply a `Merge base branch into branch` commit. Mergers must remove such false-positive co-authors when writing the squash message. Every true co-author must remain in the commit message. |
| 74 | + |
| 75 | +#### PRs targeting `main` |
| 76 | + |
| 77 | +The commit message of PRs targeting `main` is always |
| 78 | + |
| 79 | +```bash |
| 80 | +$PR_TITLE ($PR_INDEX) |
| 81 | + |
| 82 | +$REWRITTEN_PR_SUMMARY |
| 83 | +``` |
| 84 | + |
| 85 | +#### Backport PRs |
| 86 | + |
| 87 | +The commit message of backport PRs is always |
| 88 | + |
| 89 | +```bash |
| 90 | +$PR_TITLE ($INITIAL_PR_INDEX) ($BACKPORT_PR_INDEX) |
| 91 | + |
| 92 | +$REWRITTEN_PR_SUMMARY |
| 93 | +``` |
| 94 | + |
| 95 | +## Maintainers |
| 96 | + |
| 97 | +We list [maintainers](../MAINTAINERS) so every PR gets proper review. |
| 98 | + |
| 99 | +#### Review expectations |
| 100 | + |
| 101 | +Every PR **must** be reviewed by at least two maintainers (or owners) before merge. **Exception:** after one week, refactoring PRs and documentation-only PRs need only one maintainer approval. |
| 102 | + |
| 103 | +Maintainers are expected to spend time on code reviews. |
| 104 | + |
| 105 | +#### Becoming a maintainer |
| 106 | + |
| 107 | +A maintainer should already be a Gitea contributor with at least four merged PRs. To apply, use the [Discord](https://discord.gg/Gitea) `#develop` channel. Maintainer teams may also invite contributors. |
| 108 | + |
| 109 | +#### Stepping down, advisors, and inactivity |
| 110 | + |
| 111 | +If you cannot keep reviewing, apply to leave the maintainers team. You can join the [advisors team](https://github.com/orgs/go-gitea/teams/advisors); advisors who want to review again are welcome back as maintainers. |
| 112 | + |
| 113 | +If a maintainer is inactive for more than three months and has not left the team, owners may move them to the advisors team. |
| 114 | + |
| 115 | +#### Account security |
| 116 | + |
| 117 | +For security, maintainers should enable 2FA and sign commits with GPG when possible: |
| 118 | + |
| 119 | +- [Two-factor authentication](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication) |
| 120 | +- [Signing commits with GPG](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) |
| 121 | + |
| 122 | +Any account with write access (including bots and TOC members) **must** use [2FA](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication). |
| 123 | + |
| 124 | +## Technical Oversight Committee (TOC) |
| 125 | + |
| 126 | +At the start of 2023, the `Owners` team was dissolved. Instead, the governance charter proposed a technical oversight committee (TOC) which expands the ownership team of the Gitea project from three elected positions to six positions. Three positions are elected as it has been over the past years, and the other three consist of appointed members from the Gitea company. |
| 127 | +https://blog.gitea.com/quarterly-23q1/ |
| 128 | + |
| 129 | +### TOC election process |
| 130 | + |
| 131 | +Any maintainer is eligible to be part of the community TOC if they are not associated with the Gitea company. |
| 132 | +A maintainer can either nominate themselves, or can be nominated by other maintainers to be a candidate for the TOC election. |
| 133 | +If you are nominated by someone else, you must first accept your nomination before the vote starts to be a candidate. |
| 134 | + |
| 135 | +The TOC is elected for one year, the TOC election happens yearly. |
| 136 | +After the announcement of the results of the TOC election, elected members have two weeks time to confirm or refuse the seat. |
| 137 | +If an elected member does not answer within this timeframe, they are automatically assumed to refuse the seat. |
| 138 | +Refusals result in the person with the next highest vote getting the same choice. |
| 139 | +As long as seats are empty in the TOC, members of the previous TOC can fill them until an elected member accepts the seat. |
| 140 | + |
| 141 | +If an elected member that accepts the seat does not have 2FA configured yet, they will be temporarily counted as `answer pending` until they manage to configure 2FA, thus leaving their seat empty for this duration. |
| 142 | + |
| 143 | +### Current TOC members |
| 144 | + |
| 145 | +- 2024-01-01 ~ 2024-12-31 |
| 146 | + - Company |
| 147 | + - [Jason Song](https://gitea.com/wolfogre) <i@wolfogre.com> |
| 148 | + - [Lunny Xiao](https://gitea.com/lunny) <xiaolunwen@gmail.com> |
| 149 | + - [Matti Ranta](https://gitea.com/techknowlogick) <techknowlogick@gitea.com> |
| 150 | + - Community |
| 151 | + - [6543](https://gitea.com/6543) <6543@obermui.de> |
| 152 | + - [delvh](https://gitea.com/delvh) <dev.lh@web.de> |
| 153 | + - [John Olheiser](https://gitea.com/jolheiser) <john.olheiser@gmail.com> |
| 154 | + |
| 155 | +### Previous TOC/owners members |
| 156 | + |
| 157 | +Here's the history of the owners and the time they served: |
| 158 | + |
| 159 | +- [Lunny Xiao](https://gitea.com/lunny) - 2016, 2017, [2018](https://github.com/go-gitea/gitea/issues/3255), [2019](https://github.com/go-gitea/gitea/issues/5572), [2020](https://github.com/go-gitea/gitea/issues/9230), [2021](https://github.com/go-gitea/gitea/issues/13801), [2022](https://github.com/go-gitea/gitea/issues/17872), 2023 |
| 160 | +- [Kim Carlbäcker](https://github.com/bkcsoft) - 2016, 2017 |
| 161 | +- [Thomas Boerger](https://gitea.com/tboerger) - 2016, 2017 |
| 162 | +- [Lauris Bukšis-Haberkorns](https://gitea.com/lafriks) - [2018](https://github.com/go-gitea/gitea/issues/3255), [2019](https://github.com/go-gitea/gitea/issues/5572), [2020](https://github.com/go-gitea/gitea/issues/9230), [2021](https://github.com/go-gitea/gitea/issues/13801) |
| 163 | +- [Matti Ranta](https://gitea.com/techknowlogick) - [2019](https://github.com/go-gitea/gitea/issues/5572), [2020](https://github.com/go-gitea/gitea/issues/9230), [2021](https://github.com/go-gitea/gitea/issues/13801), [2022](https://github.com/go-gitea/gitea/issues/17872), 2023 |
| 164 | +- [Andrew Thornton](https://gitea.com/zeripath) - [2020](https://github.com/go-gitea/gitea/issues/9230), [2021](https://github.com/go-gitea/gitea/issues/13801), [2022](https://github.com/go-gitea/gitea/issues/17872), 2023 |
| 165 | +- [6543](https://gitea.com/6543) - 2023 |
| 166 | +- [John Olheiser](https://gitea.com/jolheiser) - 2023 |
| 167 | +- [Jason Song](https://gitea.com/wolfogre) - 2023 |
| 168 | + |
| 169 | +## Governance Compensation |
| 170 | + |
| 171 | +Each member of the community elected TOC will be granted $500 each month as compensation for their work. |
| 172 | + |
| 173 | +Furthermore, any community release manager for a specific release or LTS will be compensated $500 for the delivery of said release. |
| 174 | + |
| 175 | +These funds will come from community sources like the OpenCollective rather than directly from the company. |
| 176 | +Only non-company members are eligible for this compensation, and if a member of the community TOC takes the responsibility of release manager, they would only be compensated for their TOC duties. |
| 177 | +Gitea Ltd employees are not eligible to receive any funds from the OpenCollective unless it is reimbursement for a purchase made for the Gitea project itself. |
| 178 | + |
| 179 | +## TOC & Working groups |
| 180 | + |
| 181 | +With Gitea covering many projects outside of the main repository, several groups will be created to help focus on specific areas instead of requiring maintainers to be a jack-of-all-trades. Maintainers are of course more than welcome to be part of multiple groups should they wish to contribute in multiple places. |
| 182 | + |
| 183 | +The currently proposed groups are: |
| 184 | + |
| 185 | +- **Core Group**: maintain the primary Gitea repository |
| 186 | +- **Integration Group**: maintain the Gitea ecosystem's related tools, including go-sdk/tea/changelog/bots etc. |
| 187 | +- **Documentation Group**: maintain related documents and repositories |
| 188 | +- **Translation Group**: coordinate with translators and maintain translations |
| 189 | +- **Security Group**: managed by TOC directly, members are decided by TOC, maintains security patches/responsible for security items |
| 190 | + |
| 191 | +## Roadmap |
| 192 | + |
| 193 | +Each year a roadmap will be discussed with the entire Gitea maintainers team, and feedback will be solicited from various stakeholders. |
| 194 | +TOC members need to review the roadmap every year and work together on the direction of the project. |
| 195 | + |
| 196 | +When a vote is required for a proposal or other change, the vote of community elected TOC members count slightly more than the vote of company elected TOC members. With this approach, we both avoid ties and ensure that changes align with the mission statement and community opinion. |
| 197 | + |
| 198 | +You can visit our roadmap on the wiki. |
0 commit comments