|
1 |
| -# auth-gateway Governance |
| 1 | +# `auth-gateway` Governance |
2 | 2 |
|
3 | 3 | This document defines project governance for the project.
|
4 | 4 |
|
5 | 5 | ## Voting
|
6 | 6 |
|
7 |
| -todo |
| 7 | +In the event of an important decision that needs to be taken, both maintainers must come to a consensus for the decision to be approved. |
| 8 | +If a consensus cannot be reached, the matter shall be put on hold until such a time where a consensus can be agreed upon. |
8 | 9 |
|
9 | 10 | ## Changes in Maintainership
|
10 | 11 |
|
11 |
| -Contributors who are interested in becoming a maintainer, if performing relevant responsibilities, should discuss their interest with the existing maintainers. New maintainers must be nominated by an existing maintainer and must be elected by 2/3 majority vote. |
12 |
| - |
13 |
| -We do not expect anyone to make a permanent commitment to be a auth-gateway maintainer forever. After all, circumstances change, people get new jobs, new interests, and may not be able to continue contributing to the project. At the same time, we need to keep the list of maintainers current in order to have effective governance. People may be removed from the current list of maintainers via one of the following ways: |
| 12 | +Contributors who are interested in becoming a maintainer, if performing relevant responsibilities, should discuss their interest with the existing maintainers. |
| 13 | +New maintainers must be nominated by an existing maintainer and unanimously approved by the current maintainers. |
14 | 14 |
|
| 15 | +We do not expect anyone to make a permanent commitment to be a `auth-gateway` maintainer forever. |
| 16 | +Circumstances change, people get new jobs, new interests, and may not be able to continue contributing to the project. |
| 17 | +However, to maintain effective governance, we need to keep the list of maintainers current. |
| 18 | +People may be removed from the current list of maintainers via one of the following ways: |
15 | 19 |
|
16 | 20 | * They can resign
|
17 | 21 | * If they stop contributing to the project for a period of 6 months or more
|
18 |
| -* By a 2/3 majority vote from active maintainers |
| 22 | +* By unanimous agreement of the other active maintainers |
19 | 23 |
|
20 |
| -Former maintainers are recognized with an honorary *Emeritus Maintainer* status, and have their names permanently listed in the [README](README.md) as a form of gratitude for their contributions. |
| 24 | +Former maintainers are recognized with an honorary *Emeritus Maintainer* status, and have their names permanently listed in the README as a form of gratitude for their contributions. |
21 | 25 |
|
22 | 26 | ## Approving PRs
|
23 | 27 |
|
24 |
| -PRs may be merged after receiving at least one positive votes (not sure about this sentence). If the PR author is a maintainer, this counts as a vote. |
| 28 | +PRs may be merged after receiving approval from both maintainers. |
| 29 | +If the PR author is a maintainer, the approval of the other maintainer is required. |
25 | 30 |
|
26 | 31 | ## Changes in Governance
|
27 | 32 |
|
28 |
| -All changes in Governance require a 2/3 majority vote. |
| 33 | +All changes in Governance require unanimous agreement of the maintainers. |
0 commit comments