Skip to content
This repository has been archived by the owner on Nov 9, 2017. It is now read-only.

Identify the roles and responsibility of being a member of this WG #65

Closed
juliepagano opened this issue Dec 18, 2015 · 24 comments
Closed

Comments

@juliepagano
Copy link
Contributor

This comes from discussion of #40 and #39 during the 2015-12-18 meeting. The goal of this issue is to get an initial proposal together identifying the major roles and responsibilities of members of this working group. This will be useful for helping us contrast members vs. collaborators.

@juliepagano
Copy link
Contributor Author

This is also potentially related to #32, so it will be useful to have some cross-discussion there.

@ashleygwilliams
Copy link
Contributor

status? @beaugunderson @juliepagano

@beaugunderson
Copy link
Contributor

@ashleygwilliams sorry, dropped this on the floor--will work on it tonight

@beaugunderson
Copy link
Contributor

ok; i pulled together a lot of what we've already been doing and what we've talked about this group doing; i've probably missed a lot but here's a start:

these are things that have come up already or that we've talked about doing in the future:

  • moderation
  • admissions
    • evaluating & voting on applicants
    • writing acceptance or rejection messages
  • discussions
    • all of the github issues, for example
  • outreach to other communities (for finding potential members)
  • creating meeting agendas
  • attending and participating in meetings
  • taking meeting notes
  • setting up google hangouts On Air
  • facilitating meetings
  • providing resources for teaching facilitation
  • participating in slack (or similar group chat)
  • participating in github issues
  • writing
    • for example the code of conduct, charter, etc.
  • making pull requests
    • for example the code of conduct, charter, and email alias PRs
  • responding to outside parties
    • like the request for guidance from microsoft
  • responding to emails that come in on the inclusivity@ email alias
  • ops/management for adding new members, removing old members (updating github orgs, email aliases, slack, managing public and private spaces, etc.)
  • contracting outside help

questions:

  • difference between a WG member and a collaborator? (maybe that's a separate issue)

@juliepagano
Copy link
Contributor Author

Something that would be useful here is expectation around availability and work. How responsive do we want members of the WG to be to requests? How many hours a week/month/whatever do we expect from people? That's a big thing and I'm not sure something we have group consensus on. Maybe worth discussing at our next meeting.

@juliepagano
Copy link
Contributor Author

@beaugunderson that list you wrote up seems to cover the list of things we do well.

Below is an initial stab at some potential considerations for WG member vs. collaborator. Maybe someone can adjust/expand on this.

WG Member:

  • Someone who makes a regular time and responsiveness commitment (see question above about what those should be) to contributing to the WG.
  • Has access to private WG communications (e.g. slack, email list).
  • Gets priority for participating in WG meetings (because we have limited slots in hangouts).
  • Participates by contributing on github (e.g. issues, PRs) and on private channels (e.g. slack, email list).
  • Responsible parties for WG deliverables.
  • Can speak for the group in outreach, emails, etc.

Collaborator:

  • Does not have time/responsiveness commitments.
  • Does not have access to private WG communications.
  • Can participate in WG meetings when space allows.
  • Participates by contributing on github (e.g. commenting on issues, making pull requests).
  • Can help with WG deliverables, but are not the final responsible party.
  • Cannot speak for the group in outreach, emails, etc.

@beaugunderson
Copy link
Contributor

@juliepagano agreed re: expectations of responsiveness/time commitments; maybe a straw SLA proposal would help with that (so we could work backwards)?

@ashleygwilliams
Copy link
Contributor

my initial thoughts:

  • should be available for 4/5 meetings, is shipping a thing (with others help, or solo) 1/month?

@ashleygwilliams
Copy link
Contributor

those are all "at least"

@juliepagano
Copy link
Contributor Author

Have we clarified how often meetings are going to happen? Is it twice a month now? Some considerations will have to happen there if the WG gets bigger than the size limits of hangouts.

Shipping a thing once a month is vague because projects will vary pretty heavily in size. A time commitment seems like a more concrete thing to me.

@juliepagano
Copy link
Contributor Author

Also, maybe an hours/week commitment to indicate everyone should be participating at least once a week to keep with the "ship every two weeks" idea we've been trying.

@ashleygwilliams
Copy link
Contributor

i'd like to keep trying every 2 weeks until we start having serious feels about it working/not-working. so that shakes to around twice a month, a little less.

@varjmes
Copy link
Contributor

varjmes commented Jan 16, 2016

Hey everyone! 👋

Someone who makes a regular time and responsiveness commitment (see question above about what those should be) to contributing to the WG.
Has access to private WG communications (e.g. slack, email list).
Gets priority for participating in WG meetings (because we have limited slots in hangouts).
Participates by contributing on github (e.g. issues, PRs) and on private channels (e.g. slack, email list).
Responsible parties for WG deliverables.
Can speak for the group in outreach, emails, etc.
Collaborator:

Does not have time/responsiveness commitments.
Does not have access to private WG communications.
Can participate in WG meetings when space allows.
Participates by contributing on github (e.g. commenting on issues, making pull requests).
Can help with WG deliverables, but are not the final responsible party.
Cannot speak for the group in outreach, emails, etc.

I think this is a good explanation. The most important thing being defining "hey you can still take part without having to commit all your time to this".

I myself would like to be a WG Member but I am not very confident about being on camera/talking to people I haven't interacted with before (though I become comfortable over time) so I'd probably have to be a collaborator (if ever invited to join in the inclusivity efforts).

Has access to private WG communications (e.g. slack, email list).

Is there an ability to have access to a public channel in the Slack? I think I'd really struggle and feel excluded if I couldn't interact with WG members in real time (if, again, I was a collaborator, which I am not), you would miss out on a lot of context as you can only garner so much from GitHub discussions.

Everything else seems awesome.

Is there somewhere we've defined where a person can join up? @ashleygwilliams said for me to czech out this issue and join up, but this doesn't seem to be the place to work out how to join.

Thanks! 💖

PS. The criteria for joining also includes 'has to be part of the ORG, or has to be involved in the wider node.js' community. Are there exceptions to the rule as there are a lot of cool people out there who may want to get involved but can't because of this.

@juliepagano
Copy link
Contributor Author

There's some discussions going on over in #81 about public vs. private. I'd definitely like us to have a place to include collaborators and hopefully leave the private discussions to sensitive topics only relevant to WG members.

@varjmes
Copy link
Contributor

varjmes commented Jan 16, 2016

Thanks, will check that out :)

@nebrius
Copy link
Contributor

nebrius commented Jan 19, 2016

Bit of a technical question, when we say "collaborator," do we mean Node.js collaborator, aka https://github.com/nodejs/node#collaborators? Will this be our own term, and does it confer commit privileges?

More generally, is there a difference between a collaborator and a rando in terms of conferred rights and responsibilities? Or is it a rando who wants to talk, and simply has a GitHub account?

@edef1c
Copy link

edef1c commented Jan 19, 2016

👍 on clearly defining these things (I've been absent for a variety of reasons, but knowing what's expected helps a lot with motivating myself to contribute / figuring out whether it's useful for me to be a member)

@varjmes
Copy link
Contributor

varjmes commented Jan 21, 2016

so the inclusivity meeting just happened and this issue was discussed.
@nebrius said the following:

one point is that collaborators are non-voting

What do you mean here by non-voting? Non-voting on things that are voted on by the WG? As I have applied to be a collaborator I just wanted to note that I am actually a voting member of the Foundation, having joined over the weekend as an individual member. I think you mean non-voting in the "would have no votes in democratic decision made in the WG" but as I was confused, it's always best to ask!

@nebrius
Copy link
Contributor

nebrius commented Jan 21, 2016

Yes, sorry, I do mean non-voting on things that are voted on by this WG. More specifically, this is basically clarification for how we will implement the consensus seeking process in practice, and how that ties in to working group membership as defined by the TSC.

@varjmes
Copy link
Contributor

varjmes commented Jan 22, 2016

Awesome, thanks for the clarification!

@carlosrymer
Copy link

Hi everybody!

This is a great discussion and it looks like the team is getting close on specifying some concrete expectations for members vs. collaborators. I'd like to throw out one idea specific to WG members. Given that there's an expected limit to the number of WG members at any given time, I think it would be great to provide rotation opportunities.

If there are people in the community that would like to become WG members, they can join a wait list for when current WG members' terms expires. Terms could be as much as two years or until a WG member decides to move on, or something around that concept.

This would allow the WG to change over time and also to allow others from the community to participate in the future.

@ghost
Copy link

ghost commented Feb 17, 2016

@carlosrymer that sounds like a good plan. do any other WGs employ this concept as well?

@nebrius
Copy link
Contributor

nebrius commented Apr 18, 2016

Now that we've landed #106, can we close this issue?

@scottgonzalez
Copy link
Contributor

I think so. If we want to clarify or expand any of the responsibilities, we can open another issue with specifics.

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

No branches or pull requests

8 participants