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 all commits
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
88 changes: 88 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,88 @@
# 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.
- Participation in the member slack channel.
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we change this from "member slack channel" to "working group Slack channel"? Long term, our goal is to open the slack channel up to people other than members, and this way we don't have to reword later (and we also can't forget too reword it) :)

- 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.
- Enforcement of the working group's [code of conduct](https://github.com/nodejs/inclusivity/blob/master/CODE_OF_CONDUCT.md).
- 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.


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 non-member role.

As representatives of the working group, members are expected to set an example with the [code of conduct](https://github.com/nodejs/inclusivity/blob/master/CODE_OF_CONDUCT.md). Violations of the code of conduct may lead to loss of member status and/or removal from the working group.

#### 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)).
- Github:
- Content: view, edit.
- Issues: view, create, comment, edit, close.
- Pull requests: create, comment, merge, close.
- Moderation of issues, pull requests, etc.
- Has priority for participation in working group meetings (because there are limited slots available in google hangouts).

### Non-members
Non-members are people who contribute to the inclusivity working group, but do not have specific responsibilities and commitments.

#### Becoming a non-member
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we change this to something like "Contributing as a non-member"? There's not really a process to go through to contribute, but this sort of implies to me that there is.

I think it could also be useful to add a blurb along the lines of "There is no admissions policy for becoming a non-member, anyone can contribute as long as they adhere to the Code of Conduct)."

What do you think?

Copy link

Choose a reason for hiding this comment

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

I tried to re-word this a few times but ultimately found the problem with my phrasing to be with 'non-member' and attempting to work around it. I'm sure there's been discussions about this that I've missed, but why not follow a similar pattern to other working groups within Node.js about contributing/participating? I'm trying to think of a more welcoming term...

Copy link
Contributor

Choose a reason for hiding this comment

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

I think you're right, and I like the idea of referring to this role as a "contributor," since it's an official term in GitHub land. I think the name stuck because I called them that in a discussion once.

We were originally contemplating three types of people: contributors (aka anyone on GitHub that hasn't been blocked), members, and something in between we called "collaborator." We decided to get rid of this middle type to normalize membership types across the Node org, and I think I used the term to emphasis "everyone who isn't a member" to emphasize the difference with the previous setup.

Copy link

Choose a reason for hiding this comment

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

i'm for contributor as well. wouldn't fit too well for people that only haven't been banned, since a contributor is already an 'elevated' status in github teminology. plus the term 'non-member', when taken out of context, doesn't sound fitting and just weird

Anyone can be a non-member. Review the [code of conduct](https://github.com/nodejs/inclusivity/blob/master/CODE_OF_CONDUCT.md) before participating to familiarize yourself with expected behavior when contributing to the working group.

***Insert steps for getting access to the public slack here.***
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we can leave this out for now, and add it back in a separate PR once #81 gets sorted out.


### Responsibilities

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

Non-member 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).

Non-members are expected to follow the [code of conduct](https://github.com/nodejs/inclusivity/blob/master/CODE_OF_CONDUCT.md). Violations of the code of conduct may lead to removal from the working group.

#### Permissions

Non-members 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.
- Github:
- Content: view.
- Issues: view, create, comment.
- Pull requests: create, comment.
- May participate in working group meetings when space allows.

Non-members **DO NOT** have permission to do the following.

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