Changes to our nomination process

[mcollina]

Currently, our nomination process requires a single collaborator to object to it without any discussion and without providing any reason.

This is potentially against our code of conduct as it allows a venue of discrimination:

We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.

I understand that this process is subjected to the usual Consensus Seeking approach we follow, e.g. "in case of disagreement, it goes to the TSC", but a few people told me this was not the case. Therefore, I think we should clarify/change it to avoid possible discrimination.

[aduh95]

I think if someone blocks a nomination on discriminatory basis, you should consider remove the objector from their collaborator team – at which point, the nomination passes as currently only collaborators can veto a nomination.

What is the change you are suggesting exactly?

[mcollina]

The source of the confusion come from our same governance file, that states that's the responsibility of the TSC to maintain the list of collaborators.

I propose we change

The nomination passes if no collaborators oppose it after one week. Otherwise, the nomination fails.

to

The nomination passes if no collaborators oppose it after one week. Otherwise, the nomination fails. The TSC has the right to overcome this objection with a vote.

[benjamingr]

I think the ability to block is very valuable since it's a lot harder to come out and block than avoid the conflict. I agree with @aduh95 about our current process being able to address this situation already.

So I think I like our current process better since it makes it more likely for people to object and if an objection is discriminatory or in bad faith we can remove the offending collaborator for the CoC violation then.

[mcollina]

My understanding is that's not our current process, point of view that is shared by @jasnell: the TSC is responsible for curating the list of collaborators.

This means abrogating one of the prime responsibilities of the leadership of the project, a form of contention and instability. There should be no vetoes.

[aduh95]

a form of contention and instability

I'm really not convinced you'd get more stability by forcing people to work together if they don't want to.

What about this instead: we keep the current process, and explicitly add a rule saying "objecting to a collaborator nomination must be justified with a reason that is communicated (privately) with the TSC". So if a nomination receives an objection, the TSC can vote to remove the objector from the collaborator list if the reason is deemed unreasonable¹, or the nomination doesn't pass.

Footnotes

1. more likely a TSC member will volunteer to work things out with the objector and nominee to resolve the objection, but let's discuss the most extreme case for the sake of the argument. ↩

[aduh95]

Because let's assume the following scenario:

1. Person A gets nominated.
2. Person B (who is an existing collaborator) objects to that nomination.
3. The TSC votes to override the objection.
4. A public nomination issue is opened to the nodejs/node repo.
5. Person B makes their objection public on the nomination issue.

Now what? The project has failed everyone in this scenario, everyone involved will look bad. You may ask: "why would Person B make their objection public?". Well I think either of the following must be true:

• Person B is objecting in good faith. They really think Person A should not be a collaborator. I think that gives them a moral obligation to maintain their objection. (note that it's definitely possible that they will cave under the peer pressure and keep that objection to themself, but that doesn't sound like an healthy environment for OSS collaboration, I assume the next logical step for them is to retire from the project).
• Person B is objecting in bad faith. In this case, why keep them as collaborator?

I really don't think your proposal would help the project, it seems to me it's putting us at risk for little to no benefit. I'm happy to be convinced otherwise.

[mcollina]

The Node.js project charter, as approved by the OpenJS CPC, clearly states in .8:

Individuals making significant and valuable contributions are made Collaborators and given commit-access to the project. These individuals are identified by the TSC and their addition as Collaborators is discussed during a TSC meeting.

This clearly states that it's the TSC responsibility to identify and name the collaborators. The TSC-Charter is the most essential document in our project and trumps everything else. Therefore, nominations should follow our Consensus Seeking process.

The nomination process was changed by @Trott in nodejs/node#27317, to simplify it (and reduce the work for the TSC). I don't think @Trott intended to move it to the unanimous consent of all collaborators, and that's not my read of that PR, nor it was framed as such. Even if it was, it's clearly against our charter and should be clarified.

(Note that we used to announce new collaborators in meetings because of our charter)

---

What about this instead: we keep the current process, and explicitly add a rule saying "objecting to a collaborator nomination must be justified with a reason that is communicated (privately) with the TSC". So if a nomination receives an objection, the TSC can vote to remove the objector from the collaborator list if the reason is deemed unreasonable1, or the nomination doesn't pass.

Why would somebody put themselves in a "only one of us can be here" situation, if the collaborator already meets all other criteria to be nominated? This can only be if there was some private issue between the two. I don't think it's for us to decide on that, because it would be against our CoC pledge:

We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.

Therefore, according to your proposal/interpreatation, opposing a nomination based on a private issue between two parties is a CoC violation by itself.

[aduh95]

Just to be clear I’m not defending that the TSC doesn’t have control over the collaborator memberships, what I’m challenging is that voting to override objections is an acceptable way of “resolving” such situation.

Why would somebody put themselves in a "only one of us can be here" situation, if the collaborator already meets all other criteria to be nominated?

I don’t know, but when it happens I think the TSC needs to be prepared and not ignore the situation, which would be rather bad.

[jasnell]

must be justified with a reason that is communicated (privately) with the TSC". So if a nomination receives an objection, the TSC can vote to remove the objector from the collaborator list if the reason is deemed unreasonable1, or the nomination doesn't pass.

My concern with this language is that the determination of "unreasonable" is quite vague. It could have the effect of making it less likely someone will object to a nomination when they otherwise would feel the need to given that there's a risk it could blow back on them.

...what I’m challenging is that voting to override objections is an acceptable way of “resolving” such situation.

Generally speaking the TSC should always seek to avoid a situation where a vote is required. In the case of collaborator nominations, that should mean taking steps to see if there are other remedies around the problem. Objections to a nomination should always been carefully considered and weighed. However, if the issue is intractable, and the TSC feels the objection is not warranted, then the TSC should have the option of moving forward despite the objection.

[joyeecheung]

Why would somebody put themselves in a "only one of us can be here" situation, if the collaborator already meets all other criteria to be nominated? This can only be if there was some private issue between the two. I don't think it's for us to decide on that, because it would be against our CoC pledge:

I think there are many cases that can lead to this situation. For a very hypothetical example (and I definitely don't mean that this is happening, just a very hypothetical example), suppose a collaborator knows that a nominee is a sex offender (again I definitely don't mean anyone on the project is a sex offender, just a hypothetical case, partly inspired by something that happened in real life that you may have heard about from tech news, but let's make it extreme and say this is a sex offender that has gotten away with the legal system, for the sake of hypothesis). For many reasons (e.g. to protect the victims), they could not come out and explain the potential danger of this nominee, but they may feel the moral obligation to avoid having this person in any position of power, including being a committer in a well-known open source project. This private issue may or may not even happen between the two specifically. We all work online and we know little about each other's offline identity. Being a collaborator gives someone more justification to go to our offline events and thus this can give someone the moral obligation to prevent a sex offender to appear in our offline events and with some sort of prestige/trustworthiness in the form of committership.

Therefore, according to your proposal/interpreatation, opposing a nomination based on a private issue between two parties is a CoC violation by itself.

In this case, Should the project be welcoming to a sex offender? Well that can be subject to discussion, some people believe that if someone can get away with the legal system they don't count as a sex offender, or even if they do they deserve a second chance. Would the project being welcoming to a sex offender turned out to be a dangerous thing to do and be unwelcoming to contributors that could fall under another offense? Yes, it could even damage the image of the project if this went public. And the person objecting to the nomination could totally act in good faith and believed that they were protecting others in the project to avoid future CoC violations, or just protecting the project in general. This could be a difficult case to resolve from the TSC side, and this is totally hypothetical, I repeat, but just throwing it out there to make a case - I don't think it's fair to say objecting to a nomination based on a private issue that happens outside the project, by itself, constitutes as a CoC violation. They could totally do this because they want to ensure that we are

an open, welcoming, diverse, inclusive, and healthy community.

(and what makes a community inclusive and healthy is again up to personal interpretation).