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

Membership review #215

Closed
mhdawson opened this issue Jul 12, 2018 · 22 comments
Closed

Membership review #215

mhdawson opened this issue Jul 12, 2018 · 22 comments

Comments

@mhdawson
Copy link
Member

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
Copy link
Contributor

naugtur commented Jul 12, 2018

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
Copy link

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

@mhdawson
Copy link
Member Author

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
Copy link
Member

Qard commented Jul 12, 2018

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
Copy link

rmg commented Jul 12, 2018

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
Copy link

@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
Copy link
Member

watson commented Jul 13, 2018

@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
Copy link
Member

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
Copy link

@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
Copy link
Member

watson commented Jul 13, 2018

@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
Copy link

@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
Copy link
Member

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.

@mhdawson mhdawson changed the title Membership reivew Membership review Jul 17, 2018
@hekike
Copy link
Contributor

hekike commented Jul 18, 2018

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

@mcollina
Copy link
Member

I'll keep being active in this group.

@jasnell
Copy link
Member

jasnell commented Jul 18, 2018

As will i

@hashseed
Copy link
Member

... and my axe!

I mean, I will continue to be active.

@ofrobots
Copy link
Contributor

I'll keep being active in this group.

@Flarna
Copy link
Member

Flarna commented Jul 18, 2018

I will for sure monitor the activities and try to give some input. Not sure if this is enough for a membership.

@mhdawson
Copy link
Member Author

In this issue I was just asking if people were ok with the process, but I'll make sure to transfer over those who have already responded.

It will be a week that the issue was opened tomorrow, unless there are objections before then I'll open the issue asking people to confirm they still want to be active.

@yunong
Copy link
Member

yunong commented Jul 23, 2018 via email

@mmarchini
Copy link
Contributor

Still active as well

@mhdawson
Copy link
Member Author

mhdawson commented Aug 2, 2018

opened #217 for the review.

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