Collaborator Changes - More Privacy about admin HOT 15 OPEN

We can't have the TSC be the only deciders on whether new collaborators can be added. We can maybe have an initial round veto, but assuming no TSC member objects via email we still need to run a nomination by all collaborators before it can be approved.

from admin.

• Opening an issue in the private moderation repo to discuss members' conduct is no longer allowed, instead people requesting moderation of members' posts should email [email protected] , this is for better privacy of the member.

I imagine we'd also want to be clear that people can reach out to individual Moderation Team members instead if they are more comfortable with that. This would be particularly useful in the case where the behavior being discussed is that of another Moderation Team member (although hopefully that never comes up).

from admin.

No. I think we should change this process completely to maintain privacy in a better way.

If the nomination is public to the collaborators and if it does not go through, people would know about that (even if the motives are not clear).

Here is a process that have more privacy:

1. the collaborator that does the nomination send an email to [email protected]
2. the TSC approves or rejects via email

This has the advantage of not having disjoint communication across multiple medium. It's easy to miss to correlate a mail with a github issue and viceversa.
The disadvantage is that only tsc members can object, however I consider this a minor concern give the current number of people in the TSC.

from admin.

I agree with all the statements here, but I wonder by making "blockings/ -1" privates we loose the chance of being able to convince the people providing the "-1" of a counterargument.

Because by the bylaws even a single -1 would result in the nominee not being accepted.

from admin.

(Aside: I wonder if the email address might routinely send things to the spam folder. We should probably get someone to look closely at the DMARC setup there.)

from admin.

I agree with all the statements here, but I wonder by making "blockings/ -1" privates we loose the chance of being able to convince the people providing the "-1" of a counterargument.

Usually when a collaboration is blocked the nominator goes to objectors and tries to work things out (e.g. ask what the nominee has to do in order to get accepted), this is to the best of my knowledge is already done in private.

from admin.

I agree with all the statements here, but I wonder by making "blockings/ -1" privates we loose the chance of being able to convince the people providing the "-1" of a counterargument.

Usually when a collaboration is blocked the nominator goes to objectors and tries to work things out (e.g. ask what the nominee has to do in order to get accepted), this is to the best of my knowledge is already done in private.

But if the objection becomes private, how does the nominator knows who to reach out to?

from admin.

The objection is private to the nominator and the TSC so ideally through that, people can block without doing so publicly today too if I understand our process correctly.

from admin.

The objection is private to the nominator and the TSC so ideally through that, people can block without doing so publicly today too if I understand our process correctly.

Aha! Didn't get that from the initial thread; maybe I missed it or you might want to clarify that. But that's good to know.

Edit: re-reading the initial thread made it clear!

from admin.

I’m -1 with this change. I think a better approach is to run the nomination process through the TSC mailing list. In this way everything could be done privately.

from admin.

@mcollina presented in the TSC meeting is:

• You can block by sending an email to the TSC or a TSC member privately.
• You can block by sending an email to the nominator and try to work out the differences

Does that address your concern?

from admin.

I feel strongly that the project should let collaborators object to nominations since the TSC while big isn't aware of all interactions and context in the project.

from admin.

I think it's worse leaving a nomination "hanging" without a response than having no response. This is relatively bad for the nominee, and I think we should respect their privacy too.

Ultimately, I think this change make our processes more complex without a real benefit.
However I can see a problem with individuals that had private report on moderation. While that is covered by a few members of the TSC, I concur that a larger visibility is better.

I might be wrong, but my understanding is that it's a TSC responsibility to maintain the list of collaborators, as written in:

https://github.com/nodejs/node/blob/main/GOVERNANCE.md.

In other terms, it's our responsibility to know who we let in.

from admin.

Ok, if this doesn't have consensus I don't really have time to iron things out so I'm removing the collaborator nomination change here and we keep the current process.

I'll proceed with the changes in moderation and open a PR next week.

If anyone else wants to pick up on the collaborator nomination changes to improve privacy please go ahead and open a new issue.

from admin.

Removing from TSC agenda since we discussed last week. Please put it back on the agenda if there is still something needed by from the TSC.

from admin.