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

Initial draft of roles and responsibilities. #101

Merged
merged 5 commits into from
Mar 18, 2016
Merged

Initial draft of roles and responsibilities. #101

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
a3d7fa5
Initial draft of roles and responsibilities.
Jan 31, 2016
f19578d
s/collaborator/contributor
juliepagano Feb 4, 2016
7a10e2d
Add code of conduct enforcement to list of member responsibilities.
juliepagano Feb 4, 2016
f30271b
Updates based on discussions.
juliepagano Feb 27, 2016
4fb7926
Add create issues to github permissions.
juliepagano Feb 29, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
77 changes: 77 additions & 0 deletions docs/POLICY_ROLES_RESPONSIBILITIES.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
# Roles and Responsibilities
This document outlines the major roles and responsibilities associated with the inclusivity working group.

## Roles
The inclusivity working group has two main roles for participants.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This document is long enough that it would be helpful to list the two main roles here.


### Member
Members are the core group of people responsible for the inclusivity working group. Members make a regular commitment to participating in the working group and contributing to deliverables. The target size for membership is 6-12 people.

The current list of members can be found [here](https://github.com/nodejs/inclusivity#initial-membership).

#### Becoming a member
See the [admissions policy](https://github.com/nodejs/inclusivity/blob/master/docs/POLICY_ADMISSIONS.md) for details about the process for becoming a member.

#### Responsibilities
Members are expected to commit at least 10 hours a month (**Question for PR: is this time commitment too much/little?**) towards the working group's responsibilities. Members are expected to contribute in some way every two weeks because the group delivers on a biweekly basis.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reflecting back to the meeting last week, what do you think about dropping the first sentence, at least for now?


A member's time commitment can be spent on a variety of contributions including, but not limited to:

- Preparing and participating in working group meetings. See [issue #64](https://github.com/nodejs/inclusivity/issues/64) for discussion around the roles and responsibilities for meetings.
- Developing new policies, documentation, etc. for the group (e.g. [add CONTRIBUTING.md content](https://github.com/nodejs/inclusivity/pull/88)).
- Developing resources for the wider node community (e.g. [Getting Started in Node.js Program](https://github.com/nodejs/inclusivity/issues/96)).
- Reviewing [pull requests](https://github.com/nodejs/inclusivity/pulls) on the inclusivity repository.
- Moderating [issues](https://github.com/nodejs/inclusivity/issues) on the inclusivity repository.
- Assisting with moderation outside the inclusivity repository, when the group is asked for help.
- Responding to emails and other outside requests sent to the inclusivity working group.
- Participating in discussions on the private and/or public working group slack channels.
- Outreach with other communities.
- Operations (e.g. managing membership for slack, github).
- Reviewing, voting on, and responding to membership requests.

**Question for PR: Do we want to have requirements around attending meetings? If so, I'd like them to be a little loose to account for difficulties with time zones and accessibility, so we aren't losing diversity in our membership.**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After thinking about this, I think we can leave those requirements out for now, and add them in later if it becomes an issue.


**Question for PR: Do we want to have anything about the member-only slack channel here, since we sometimes use it for discussions?**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see no harm in mentioning the members-only (private) part of the Slack channel, so someone can know their full responsibilities when they apply to join :)


**Question for PR: Do we want to add something here about responsibilities around the code of conduct? I feel like members may be held to a higher standard.**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What kind of extra responsibilities do you mean?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm thinking reinforcing that members need to follow the code of conduct. I think removing someone's status as a member would potentially be a repercussion of violating the code of conduct (not necessarily in all cases, but on a case-by-case basis).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good to me!


If a member will be unavailable to meet these responsibilities, they are expected to notify the group in a timely manner, so resources can be planned accordingly. A member who cannot maintain these responsibilities for a significant amount of time will be asked to transition to a collaborator role.

#### Permissions

Members have the following level of access and permissions for the working group.

- Are allowed to speak on behalf of the group in outreach, emails, etc.
- Have access to member-only, private slack channel.
- Receive emails sent to the working group's email ([inclusivity@nodejs.org](mailto:inclusivity@nodejs.org)).
- Have **INSERT PERMISSION/ORG LEVEL INFORMATION HERE** access on github.
- Has priority for participation in working group meetings (because there are limited slots available in google hangouts).

### Collaborator
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It sounds like we may want a different label for this role as the term "collaborator" has some different meanings outside the WG and could lead to confusion.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking "contributor" might be a better term here. I'll check it to reflect that unless I hear any objections.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does collaborator mean elsewhere? Contributor sounds good to me :)

Collaborators are people who contribute to the inclusivity working group, but do not have specific responsibilities and commitments.

#### Becoming a collaborator
**QUESTION FOR PR: Do we have a policy for becoming a collaborator? Should we? How does this work?**

### Responsibilities

Collaborators do not have any specific time or deliverable commitments. They may contribute to the working group as much or as little as they like.

Collaborator contributions may include, but are not limited to:

- Making pull requests on the inclusivity repository.
- Contribution to discussions on issues and pull requests in the inclusivity repository.
- Participating in discussions on the public working group slack channel (to be created in the near future).

#### Permissions

Collaborators have the following level of access and permissions for the working group.

- Have access to public slack channel. This does not currently exist, but will be created some time in the near future.
- Have **INSERT PERMISSION/ORG LEVEL INFORMATION HERE** access on github.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to this, it sounds like contributors will have the same GitHub permissions as Members, right? GitHub doesn't have very fine-grained controls over what people can do, unfortunately. I'm inclined to say that contributors don't have any GitHub permissions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No github permissions seems reasonable to me in that case. I basically wasn't sure.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would the harm be in contributors having GitHub permissions? It feels like by removing these, the only responsibilities a Contributor has above a 'not-contributor' is to talk in the Slack?

This comment is selfishly coming from someone who applied to be a Contributor, and who certainly wants to help with GitHub management to help the WG as much as possible (particularly when/if the repository gets as busy as it has done in the past, I would be concerned for core members if they had to do all of the GitHub management all of the time [tiring]).

Absolutely not a dealbreaker for me in terms of me joining (I'll do whatever I can to help the WG)! I'm also just wondering if it's worth having a whole role for someone who's only differentiated from others by the ability to talk in the Slack?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still thinking this through, but I'm trying to figure out if it's worth having this role as well. I'm not sure there's space for this kind of role tbqh. I feel like it will either end up being "basically a Member except for these few small differences" or "basically a non-member except for these few small differences."

For more details on what GitHub access entails, check out "read" permissions versus "write" permissions at https://help.github.com/articles/repository-permission-levels-for-an-organization/. In the case of this repo, the whole world has "read" permissions", and members have "write" permissions. It's important to note that people with "read" permission can still submit pull requests, open issues, comment on issues and pull requests, etc, which is where I feel like the bulk of the work is.

This is all just where my thought process is right now though, I'm still unsure about a lot of this and I'd love to hear from everyone else!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One important note is that the "inclusivity" team currently has access to this WG's repo and the moderation repo. I think only members should have access to the latter, so we might need two teams if we give contributors some access to github.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sup I think if they got access to the moderation repo through other means approved by other WGs/TSC/whatever, we're not responsible for that. It's just that our WG won't be giving anyone those permissions unless they are a member. Does that seem reasonable?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@juliepagano for sure there is value in that, always great to be clear on these things.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like still documenting this. Perhaps rename it to "Non-members"?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@juliepagano makes sense!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still thinking this through, but I'm trying to figure out if it's worth having this role as well.

Considering how much debate there has been about these roles, we should probably take a step back and ask the basic question: What needs are not being served by only having a members role?

To answer this question, I think we need to start by looking at what the most important aspects of being a member are. Based on what I've seen so far, I'd say the two big things are 1) voting; 2) time commitment. Basically, as a member you must be active in keeping the group alive, engaged, and aligned with the community needs.

In my opinion, the division of labor beyond those tasks should be based on a few things:

  • How much work can the WG members accomplish in a sustainable way?
  • Are there tasks that the WG must perform that don't inherently align with the needs of meeting the above criteria?
    • For example, moderating a mailing list, IRC, Slack, etc. and managing a WG are very different tasks that use different skill sets.
  • Are there tasks that can be accomplished without a large time commitment and without the ability to vote?
    • Are there people willing to do such work who are not willing or able to become a member?

I think the answers to many of these questions are fairly obvious, but determining roles based on these types of questions, rather than trying to determine tasks and permissions given a selected set of roles will probably be more productive.

- May participate in working group meetings when space allows.

Collaborators **DO NOT** have permission to do the following.

- Collaborators can not speak for the working group in outreach, emails, etc. unless explicitly given permission by members.
- Collaborators do not have access to private working group communications (e.g. private slack channel, emails sent to the working group email address).