Membership review

[mhdawson]

It may be time to review our membership list. There are quite a few people that I don't think have been active for quite a while.

What I'd suggest is:

1. Post an issue with an @ notice to all members asking they confirm they still plan to be active in the WG.
2. Remind after 2 weeks
3. After 4 weeks move all of those who have not responded to 'emeritus'
4. Allow a grace period of 4 more weeks where people can request to be added back without requiring consensus reaching by the WG.

@nodejs/diagnostics thoughts?

[naugtur]

I've not been active recently (but hoping to be back soon) and I think that'd work for me.

(edit) got back to my minor contribution to guides.

[misterdjules]

@mhdawson What are the goals of doing this? It's not clear to me what we're trying to achieve with that.

[mhdawson]

We've done this in a number of the working groups to make the README.md closer reflect reality. For example, this was just completed in the security-wg team with 13 people being moved to emeritus.

It makes it easier to figure out who people should try to talk to if they want to engage the WG and makes it more relevant/easier to refer to active members of the WG.

[Qard]

Should we allow for people to be removed from the members list in the readme, but remain in the team? Some folks might not be active right now, but would still like to stay updated on related issues.

[rmg]

Oops! I was recently going through my notifications/subscriptions trying to de-noise my inbox and removed myself from the GH group (causing #213). GitHub's UI made it so easy to do that I didn't even pause to think about updating the README.md in the process 😊

I haven't been active in this group for quite a while and should definitely be removed from the active members list. If I miss the notification on the PR that removes it, feel free to take this comment as acknowledgement.

[misterdjules]

@mhdawson

It makes it easier to figure out who people should try to talk to if they want to engage the WG and makes it more relevant/easier to refer to active members of the WG.

Shouldn't most people use the actual team GH handle though, like "at nodejs/diagnostics"? In this case if there are people in that team that are not active, that's only an annoyance for them and at this point then can just remove themselves. It does not impact the ability for people to reach out to active members.

[watson]

@misterdjules what downsides do you see to giving the current members a chance to say that they like to be removed as a member? If they want to stay members, they can just say so.

[gireeshpunathil]

One thing I wish to point out here (not necessarily to argue on any side though): I always had interest and willingness to work closely with this group, but seeing the member list count I felt there are enough people actively working on it already - not a good reason for me to stay away, but (honestly) I felt shy. Now I am looking forward to be part of this group and contribute in ways I can. Thanks!

[misterdjules]

@watson

what downsides do you see to giving the current members a chance to say that they like to be removed as a member? If they want to stay members, they can just say so.

If they'd like to be removed, they can leave the team using the "Leave team" button that GH provides, and submit a PR that removes their info from the members list. If they want to stay members, they don't have to do anything.

In general I find the added process of listing members in the README and having to maintain that list very inefficient. I'm also not sure it provides any benefit, but I understand that is subjective and that others may find that it does provide some real benefits.

I would even suggest in this case to not list members in the README and just let members leave the team on their own when they feel like it, and file an issue when they'd like to be added back if they can't do so on their own.

In any case, I don't have a strong opinion, and if people like this process that's all good!

I've seen that process used in many other working groups, and always felt like it was not providing any real benefit compared to the maintenance work it requires, which is why I thought I'd express my opinion this time even though I'm not a member of this specific group.

[watson]

@misterdjules Only existing members of the nodejs org have access to see who are members of which teams under the org. So the list in the readme serves as the publicly visible members list.

[misterdjules]

@watson

Only existing members of the nodejs org have access to see who are members of which teams under the org. So the list in the readme serves as the publicly visible members list.

Right, I understand that. I'm saying that the cost of the process required to maintain an accurate list of this membership (which is in itself a concept for which it is difficult to get a shared understanding) outweighs the (from my perspective) small benefits.

[richardlau]

Only existing members of the nodejs org have access to see who are members of which teams under the org. So the list in the readme serves as the publicly visible members list.

Right, I understand that. I'm saying that the cost of the process required to maintain an accurate list of this membership (which is in itself a concept for which it is difficult to get a shared understanding) outweighs the (from my perspective) small benefits.

#147 added directives to the README so that the list can be generated from the GitHub team via ncu-team sync, so in theory regular runs of the tooling should keep the list in sync.

[hekike]

I'm planning to be more active in the future.