@@ -144,6 +144,44 @@ Contributions can be: |
144 | 144 | * Participation in other projects, teams, and working groups of the Node.js |
145 | 145 | organization. |
146 | 146 |
|
| 147 | +Collaborators should be people volunteering to do unglamorous work because it's |
| 148 | +the right thing to do, they find the work itself satisfying, and they care about |
| 149 | +Node.js and its users. People should get collaborator status because they're |
| 150 | +doing work and are likely to continue doing work where having the abilities that |
| 151 | +come with collaborator status are helpful (abilities like starting CI jobs, |
| 152 | +reviewing and approving PRs, etc.). That will usually--but, very importantly, not |
| 153 | +always--be work involving committing to the `nodejs/node` repository. For an example |
| 154 | +of an exception, someone working primarily on the website might benefit from being |
| 155 | +able to start Jenkins CI jobs to test changes to documentation tooling. That, |
| 156 | +along with signals indicating commitment to Node.js, personal integrity, etc., |
| 157 | +should be enough for a successful nomination. |
| 158 | + |
| 159 | +It is important to understand that potential collaborators may have vastly |
| 160 | +different areas and levels of expertise, interest, and skill. The Node.js |
| 161 | +project is large and complex, and it is not expected that every collaborator |
| 162 | +will have the same level of expertise in every area of the project. The |
| 163 | +complexity or "sophistication" of an individual’s contributions, or even their |
| 164 | +relative engineering "skill" level, are not primary factors in determining |
| 165 | +whether they should be a collaborator. The primary factors do include the quality |
| 166 | +of their contributions (do the contributions make sense, do they add value, do |
| 167 | +they follow documented guidelines, are they authentic and well-intentioned, |
| 168 | +etc.), their commitment to the project, can their judgement be trusted, and do |
| 169 | +they have the ability to work well with others. |
| 170 | + |
| 171 | +#### The Authenticity of Contributors |
| 172 | + |
| 173 | +The Node.js project does not require that contributors use their legal names or |
| 174 | +provide any personal information verifying their identity. |
| 175 | + |
| 176 | +It is not uncommon for malicious actors to attempt to gain commit access to |
| 177 | +open-source projects in order to inject malicious code or for other nefarious |
| 178 | +purposes. The Node.js project has a number of mechanisms in place to prevent |
| 179 | +this, but it is important to be vigilant. If you have concerns about the |
| 180 | +authenticity of a contributor, please raise them with the TSC. Anyone nominating |
| 181 | +a new collaborator should take reasonable steps to verify that the contributions |
| 182 | +of the nominee are authentic and made in good faith. This is not always easy, |
| 183 | +but it is important. |
| 184 | + |
147 | 185 | ### Nominating a new Collaborator |
148 | 186 |
|
149 | 187 | To nominate a new Collaborator: |
@@ -153,10 +191,10 @@ To nominate a new Collaborator: |
153 | 191 | the nominee's contributions (see below for an example). |
154 | 192 | 2. **Optional but strongly recommended**: After sufficient wait time (e.g. 72 |
155 | 193 | hours), if the nomination proposal has received some support and no explicit |
156 | | - block, add a comment in the private discussion stating you're planning on |
157 | | - opening a public issue, e.g. "I see a number of approvals and no block, I'll |
158 | | - be opening a public nomination issue if I don't hear any objections in the |
159 | | - next 72 hours". |
| 194 | + block, and any questions/concerns have been addressed, add a comment in the |
| 195 | + private discussion stating you're planning on opening a public issue, e.g. |
| 196 | + "I see a number of approvals and no block, I'll be opening a public |
| 197 | + nomination issue if I don't hear any objections in the next 72 hours". |
160 | 198 | 3. **Optional but strongly recommended**: Privately contact the nominee to make |
161 | 199 | sure they're comfortable with the nomination. |
162 | 200 | 4. Open an issue in the [nodejs/node][] repository. Provide a summary of |
@@ -189,10 +227,14 @@ Example of list of contributions: |
189 | 227 | organization |
190 | 228 | * Other participation in the wider Node.js community |
191 | 229 |
|
192 | | -The nomination passes if no collaborators oppose it after one week, and if the |
193 | | -nominee publicly accepts it. In the case |
194 | | -of an objection, the TSC is responsible for working with the individuals |
195 | | -involved and finding a resolution. |
| 230 | +The nomination passes if no collaborators oppose it (as described in the |
| 231 | +following section) after one week. In the case of an objection, the TSC is |
| 232 | +responsible for working with the individuals involved and finding a resolution. |
| 233 | +The TSC may, following typical TSC consensus seeking processes, choose to |
| 234 | +advance a nomination that has otherwise failed to reach a natural consensus or |
| 235 | +clear path forward even if there are outstanding objections. The TSC may also |
| 236 | +choose to prevent a nomination from advancing if the TSC determines that any |
| 237 | +objections have not been adequately addressed. |
196 | 238 |
|
197 | 239 | #### How to review a collaborator nomination |
198 | 240 |
|
@@ -203,20 +245,48 @@ adding a feature: |
203 | 245 | * If you are neutral, or feel you don't know enough to have an informed opinion, |
204 | 246 | it's certainly OK to not interact with the nomination. |
205 | 247 | * If you think the nomination was made too soon, or can be detrimental to the |
206 | | - project, share your concerns, ideally before the public nomination is opened, |
207 | | - and avoid sharing those concerns outside of the Collaborator discussion area. |
208 | | - Ideally, list what step(s) the nominee could take that would make you |
209 | | - approve their nomination. |
210 | | - Given that there is no "Request for changes" feature in discussions and issues, |
211 | | - try to be explicit when your comment is expressing a blocking concern. |
212 | | - Similarly, once the blocking concern has been addressed, explicitly say so. |
| 248 | + project, share your concerns. See the section "How to oppose a collaborator |
| 249 | + nomination" below. |
213 | 250 |
|
214 | 251 | Our goal is to keep gate-keeping at a minimal, but it cannot be zero since being |
215 | 252 | a collaborator requires trust (collaborators can start CI jobs, use their veto, |
216 | 253 | push commits, etc.), so what's the minimal amount is subjective, and there will |
217 | 254 | be cases where collaborators disagree on whether a nomination should move |
218 | 255 | forward. |
219 | 256 |
|
| 257 | +Refrain from discussing or debating aspects of the nomination process |
| 258 | +itself directly within a nomination private discussion or public issue. |
| 259 | +Such discussions can derail and frustrate the nomination causing unnecessary |
| 260 | +friction. Move such discussions to a separate issue or discussion thread. |
| 261 | + |
| 262 | +##### How to oppose a collaborator nomination |
| 263 | + |
| 264 | +An important rule of thumb is that the nomination process is intended to be |
| 265 | +biased strongly towards implicit approval of the nomination. This means |
| 266 | +discussion and review around the proposal should be more geared towards "I have |
| 267 | +reasons to say no..." as opposed to "Give me reasons to say yes...". |
| 268 | + |
| 269 | +Given that there is no "Request for changes" feature in discussions and issues, |
| 270 | +try to be explicit when your comment is expressing a blocking concern. |
| 271 | +Similarly, once the blocking concern has been addressed, explicitly say so. |
| 272 | + |
| 273 | +Explicit opposition would typically be signaled as some form of clear |
| 274 | +and unambiguous comment like, "I don't believe this nomination should pass". |
| 275 | +Asking clarifying questions or expressing general concerns is not the same as |
| 276 | +explicit opposition; however, a best effort should be made to answer such |
| 277 | +questions or addressing those concerns before advancing the nomination. |
| 278 | + |
| 279 | +Opposition does not need to be public. Ideally, the comment showing opposition, |
| 280 | +and any discussion thereof, should be done in the private discussion _before_ |
| 281 | +the public issue is opened. Opposition _should_ be paired with clear suggestions |
| 282 | +for positive, concrete, and unambiguous next steps that the nominee can take to |
| 283 | +overcome the objection and allow it to move forward. While such suggestions are |
| 284 | +technically optional, they are _strongly encouraged_ to prevent the nomination |
| 285 | +from stalling indefinitely or objections from being overridden by the TSC. |
| 286 | + |
| 287 | +Remember that all private discussions about a nomination will be visible to |
| 288 | +the nominee once they are onboarded. |
| 289 | + |
220 | 290 | ### Onboarding |
221 | 291 |
|
222 | 292 | After the nomination passes, a TSC member onboards the new collaborator. See |
|