|
1 | | -# Docker Working Group |
2 | | - |
3 | | -The Node.js Docker project is jointly governed by a Working Group (WG) |
4 | | -that is responsible for high-level guidance of the project. |
5 | | - |
6 | | -The WG has final authority over this project including: |
7 | | - |
8 | | -* Technical direction |
9 | | -* Project governance and process (including this policy) |
10 | | -* Contribution policy |
11 | | -* GitHub repository hosting |
12 | | -* Conduct guidelines |
13 | | -* Maintaining the list of additional Collaborators |
14 | | - |
15 | | -For the current list of WG members, see the project |
16 | | -[README.md](./README.md#people). |
17 | | - |
18 | | -## Collaborators |
19 | | - |
20 | | -The [nodejs/docker-node](https://github.com/nodejs/docker-node) GitHub |
21 | | -repository is maintained by the WG and additional Collaborators who |
22 | | -are added by the WG on an ongoing basis. |
23 | | - |
24 | | -Individuals making significant and valuable contributions are made |
25 | | -Collaborators and given commit-access to the project. These |
26 | | -individuals are identified by the WG and their addition as |
27 | | -Collaborators is discussed as a pull request to this project's |
28 | | -[README.md](./README.md#people). |
29 | | - |
30 | | -_Note:_ If you make a significant contribution and are not considered |
31 | | -for commit-access log an issue or contact a WG member directly. |
32 | | - |
33 | | -Modifications of the contents of the |
34 | | -[nodejs/docker-node](https://github.com/nodejs/docker-node) repository |
35 | | -are made on a collaborative basis. Anybody with a GitHub account may |
36 | | -propose a modification via pull request and it will be considered by |
37 | | -the project Collaborators. All pull requests must be reviewed and |
38 | | -accepted by a Collaborator with sufficient expertise who is able to |
39 | | -take full responsibility for the change. In the case of pull requests |
40 | | -proposed by an existing Collaborator, an additional Collaborator is |
41 | | -required for sign-off. Consensus should be sought if additional |
42 | | -Collaborators participate and there is disagreement around a |
43 | | -particular modification. See _Consensus Seeking Process_ below for |
44 | | -further detail on the consensus model used for governance. |
45 | | - |
46 | | -Collaborators may opt to elevate significant or controversial |
47 | | -modifications, or modifications that have not found consensus to the |
48 | | -WG for discussion by assigning the ***WG-agenda*** label to a pull |
49 | | -request or issue. The WG should serve as the final arbiter where |
50 | | -required. |
51 | | - |
52 | | -For the current list of Collaborators, see the project |
53 | | -[README.md](./README.md#people). |
54 | | - |
55 | | -## WG Membership |
56 | | - |
57 | | -WG seats are not time-limited. There is no fixed size of the WG. |
58 | | -However, the expected target is between 6 and 12, to ensure adequate |
59 | | -coverage of important areas of expertise, balanced with the ability to |
60 | | -make decisions efficiently. |
61 | | - |
62 | | -There is no specific set of requirements or qualifications for WG |
63 | | -membership beyond these rules. |
64 | | - |
65 | | -The WG may add, or remove, members to and from the WG. A WG member may |
66 | | -choose to be removed from the WG by voluntary resignation. |
67 | | - |
68 | | -Changes to WG membership should be posted in the |
69 | | -[nodejs/docker-node](https://github.com/nodejs/docker-node) repository |
70 | | -as an issue or pull request with the ***WG-agenda*** label followed by |
71 | | -the consensus seeking process described below. |
72 | | - |
73 | | -No more than 1/3 of the WG members may be affiliated with the same |
74 | | -employer. If removal or resignation of a WG member, or a change of |
75 | | -employment by a WG member, creates a situation where more than 1/3 of |
76 | | -the WG membership shares an employer, then the situation must be |
77 | | -immediately remedied by the resignation or removal of one or more WG |
78 | | -members affiliated with the over-represented employer(s). |
79 | | - |
80 | | -## WG Meetings |
81 | | - |
82 | | -This working group does not meet. All discussions and decisions |
83 | | -happen in the |
84 | | -[nodejs/docker-node](https://github.com/nodejs/docker-node) repository |
85 | | -in issues and pull requests. Items that requires a decision by the |
86 | | -WG can be flagged with the ***WG-agenda*** label. |
87 | | - |
88 | | -When an issue is tagged with ***WG-agenda***, the WG may invite |
89 | | -persons or representatives from certain projects to participate in the |
90 | | -discussion in a non-voting capacity. |
91 | | - |
92 | | -## Consensus Seeking Process |
93 | | - |
94 | | -The WG follows a [Consensus |
95 | | -Seeking](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) |
96 | | -decision-making model. |
97 | | - |
98 | | -All proposed changes to the project must be made in the form of a pull |
99 | | -request to the repository (directly committing to a production branch |
100 | | -of the repository is not permitted). The consensus seeking process |
101 | | -will then follow via discussion by the WG members on that pull |
102 | | -request. Changes deemed trivial by WG members may be merged instantly |
103 | | -by any WG member, without waiting for consensus, so long as they leave |
104 | | -a note explaining the reason for the merge. |
105 | | - |
106 | | -When an agenda item has appeared to reach a consensus any WG member |
107 | | -may ask "Does anyone object?" as a final call for dissent from the |
| 1 | +# Governance |
| 2 | + |
| 3 | +The Node.js Docker image project is governed using an **open maintainer model**. |
| 4 | + |
| 5 | +This repository is no longer operated as a Node.js TSC-chartered working group. |
| 6 | +Instead, project decisions are made by maintainers in public, in this repository. |
| 7 | + |
| 8 | +## Guiding principles |
| 9 | + |
| 10 | +- Default to public discussion in issues and pull requests. |
| 11 | +- Use [Consensus Seeking](https://en.wikipedia.org/wiki/Consensus_decision-making) for decision making. |
| 12 | +- Keep decision records in-repo so contributors can follow context. |
| 13 | +- Keep a clear path from contributor → collaborator → maintainer. |
| 14 | + |
| 15 | +## Roles |
| 16 | + |
| 17 | +### Contributors |
| 18 | + |
| 19 | +Anyone who proposes changes, reports issues, reviews code, or helps users. |
| 20 | + |
| 21 | +### Collaborators |
| 22 | + |
| 23 | +Collaborators have write access and help with day-to-day maintenance: |
| 24 | + |
| 25 | +- review and merge pull requests |
| 26 | +- triage issues |
| 27 | +- help drive technical direction |
| 28 | + |
| 29 | +Collaborators are nominated by maintainers via pull request and added after |
108 | 30 | consensus. |
109 | 31 |
|
110 | | -If an agenda item cannot reach a consensus a WG member can call for a |
111 | | -closing vote. The call for a vote must be seconded by a majority of |
112 | | -the WG or else the discussion will continue. Simple majority wins. |
| 32 | +### Maintainers |
| 33 | + |
| 34 | +Maintainers are responsible for long-term stewardship of the project: |
| 35 | + |
| 36 | +- facilitate consensus and escalate unresolved final decisions to the Node.js TSC |
| 37 | +- governance and membership updates |
| 38 | +- release/publishing policy and automation oversight |
| 39 | +- security and incident handling for this repository |
| 40 | + |
| 41 | +Current maintainers: |
| 42 | + |
| 43 | +- Laurent Goderre ([LaurentGoderre](https://github.com/LaurentGoderre)) |
| 44 | +- Simen Bekkhus ([SimenB](https://github.com/SimenB)) |
| 45 | +- Peter Dave Hello ([PeterDaveHello](https://github.com/PeterDaveHello)) |
| 46 | +- Rafael Gonzaga ([rafaelgss](https://github.com/rafaelgss)) |
| 47 | +- Matteo Collina ([mcollina](https://github.com/mcollina)) |
| 48 | + |
| 49 | +## Decision making |
| 50 | + |
| 51 | +### Standard changes (code/docs/automation) |
| 52 | + |
| 53 | +- Pull requests are discussed in public. |
| 54 | +- A PR from a non-collaborator can be merged by one collaborator. |
| 55 | +- A PR from a collaborator should be approved by another collaborator before |
| 56 | + merge. |
| 57 | + |
| 58 | +### Maintainer-level decisions |
| 59 | + |
| 60 | +For governance, membership, major policy, or contentious technical changes: |
| 61 | + |
| 62 | +1. Open an issue or PR describing the decision and proposed outcome. |
| 63 | +2. Allow time for async feedback (normally at least 5 days). |
| 64 | +3. If no unresolved objections remain, a maintainer may merge/close with a |
| 65 | + summary. |
| 66 | + |
| 67 | +If a final decision cannot be made using Consensus Seeking, the issue should be |
| 68 | +escalated to the Node.js TSC (for example by requesting `tsc-agenda`). |
| 69 | + |
| 70 | +In that case, the Node.js TSC is the final arbiter, consistent with the |
| 71 | +[TSC Charter](https://github.com/nodejs/TSC/blob/main/TSC-Charter.md). |
| 72 | + |
| 73 | +## Meetings |
| 74 | + |
| 75 | +The project primarily operates asynchronously in GitHub issues and pull |
| 76 | +requests. If maintainers hold synchronous meetings, outcomes should be posted |
| 77 | +publicly in this repository. |
| 78 | + |
| 79 | +## Membership changes |
| 80 | + |
| 81 | +Collaborator and maintainer changes are proposed via pull request to `README.md` |
| 82 | +and/or this file, with rationale included in the PR description. |
| 83 | + |
| 84 | +Project access should be managed via the |
| 85 | +[@nodejs/docker team](https://github.com/orgs/nodejs/teams/docker) and kept in |
| 86 | +sync with Node.js collaborator tooling. |
113 | 87 |
|
114 | | -<a id="developers-certificate-of-origin"></a> |
| 88 | +Maintainers can also move inactive members to emeritus status through the same |
| 89 | +public process. |
115 | 90 |
|
116 | 91 | ## Developer's Certificate of Origin 1.1 |
117 | 92 |
|
118 | 93 | By making a contribution to this project, I certify that: |
119 | 94 |
|
120 | | -* (a) The contribution was created in whole or in part by me and I |
| 95 | +- (a) The contribution was created in whole or in part by me and I |
121 | 96 | have the right to submit it under the open source license |
122 | 97 | indicated in the file; or |
123 | 98 |
|
124 | | -* (b) The contribution is based upon previous work that, to the best |
| 99 | +- (b) The contribution is based upon previous work that, to the best |
125 | 100 | of my knowledge, is covered under an appropriate open source |
126 | 101 | license and I have the right under that license to submit that |
127 | | - work with modifications, whether created in whole or in part |
| 102 | + work with modifications, whether created wholly or in part |
128 | 103 | by me, under the same open source license (unless I am |
129 | 104 | permitted to submit under a different license), as indicated |
130 | 105 | in the file; or |
131 | 106 |
|
132 | | -* (c) The contribution was provided directly to me by some other |
133 | | - person who certified (a), (b) or (c) and I have not modified |
| 107 | +- (c) The contribution was provided directly to me by some other |
| 108 | + person who certified (a), (b), or (c) and I have not modified |
134 | 109 | it. |
135 | 110 |
|
136 | | -* (d) I understand and agree that this project and the contribution |
| 111 | +- (d) I understand and agree that this project and the contribution |
137 | 112 | are public and that a record of the contribution (including all |
138 | 113 | personal information I submit with it, including my sign-off) is |
139 | 114 | maintained indefinitely and may be redistributed consistent with |
140 | 115 | this project or the open source license(s) involved. |
141 | 116 |
|
142 | 117 | ## Code of Conduct |
143 | 118 |
|
144 | | -The Node.js Code of Conduct, which applies to this project, can be found at |
| 119 | +The Node.js Code of Conduct applies to this project: |
145 | 120 | <https://github.com/nodejs/admin/blob/master/CODE_OF_CONDUCT.md>. |
0 commit comments