Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Collaborator Changes - More Privacy #834

Closed
benjamingr opened this issue Sep 21, 2023 · 15 comments
Closed

Collaborator Changes - More Privacy #834

benjamingr opened this issue Sep 21, 2023 · 15 comments

Comments

@benjamingr
Copy link
Member

benjamingr commented Sep 21, 2023

I’d like to propose the following change to the collaborator nomination process:

  • The “private part” of the nomination does not include discussion of the collaborator being nominated in the thread, instead people email the nominator and CC the TSC with any objections. This is for better privacy of the collaborator nominee.
  • The “public part” of the nomination does not allow for blocking the nomination with a comment, instead people email the nominator and CC the TSC with any objections. This is for better privacy as well.
  • If someone wants to block and not let the nominator know they’re the blocker they are welcome to email the TSC or a TSC member directly and they will communicate that with the nominator and the TSC.

I’d like to propose the following amendment to moderation

  • 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 report@nodejs.org , this is for better privacy of the member.
  • Opening an issue in the moderation repo about a non-member or spam is still allowed and it’s the preferred way to report spam.

The changes are to better let people save face and since handling these issues in private often leads to better conclusions.

@ovflowd
Copy link
Member

ovflowd commented Sep 21, 2023

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.

@Trott
Copy link
Member

Trott commented Sep 21, 2023

  • 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 report@nodejs.org , 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).

@Trott
Copy link
Member

Trott commented Sep 21, 2023

(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.)

@benjamingr
Copy link
Member Author

benjamingr commented Sep 21, 2023

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.

@ovflowd
Copy link
Member

ovflowd commented Sep 21, 2023

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?

@benjamingr
Copy link
Member Author

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.

@ovflowd
Copy link
Member

ovflowd commented Sep 21, 2023

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!

@mcollina
Copy link
Member

mcollina commented Oct 4, 2023

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.

@benjamingr
Copy link
Member Author

@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?

@mcollina
Copy link
Member

mcollina commented Oct 4, 2023

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 tsc@iojs.org
  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.

@GeoffreyBooth
Copy link
Member

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.

@benjamingr
Copy link
Member Author

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.

@mcollina
Copy link
Member

mcollina commented Oct 4, 2023

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.

@benjamingr
Copy link
Member Author

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.

@mhdawson
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants