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

Add policy for membership #206

Merged
merged 8 commits into from
Oct 4, 2023
Merged
Show file tree
Hide file tree
Changes from 4 commits
Commits
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
62 changes: 57 additions & 5 deletions docs/team/becoming-member.md
Original file line number Diff line number Diff line change
@@ -1,10 +1,16 @@
# Becoming a JupyterLab Council member

## JupyterLab Council responsibilities
This document describes how to become a council member. It includes information about the two subgroups of JupyterLab Council members:
- The release group (see [Release team member](#release-team-member))
- The admin group (see [Admin team member](#github-organization-owners))

## JupyterLab Council member

### JupyterLab Council responsibilities

Active members actively carry out the responsibilities listed in the [Membership Guide Page](membership_guidelines).

## Active and inactive membership
### Active and inactive membership

There are two types of JupyterLab Council members, **active** and **inactive**.
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 should remove this as it creates ambiguity about who can vote and how one moves between being active/inactive.


Expand All @@ -31,7 +37,7 @@ This means an inactive member can "reactivate" themselves at any time by publicl

For example, a member who is going out on a long leave/vacation (>2 weeks) can temporarily change their status to inactive during their absence and immediately reactivate upon return. This isn't required, but this can relieve them from having to watch this repository for any formal votes that happen during their absence.
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think this is needed. We spent a lot of time on the decision making guide to ensure that people could go on vacation and come back without any problems. There are a couple of things we put into place to help cover that:

  1. Annual vote participation is set at 2/3. Someone can easily miss votes when they are on vacation without consequence.
  2. Votes can be extended in special situations (a key person is on vacation and simply request a vote be delayed or have a longer voting period).

The language in this PR raises questions and ambiguities (do votes missed during an inactive period count towards the 1/3 votes someone is allowed to miss each year? can I vote while inactive if I want?) without solving any concrete problems not already handled by the decision making guide. I realize this is older language, so this removal could be handled in a separate PR.

Copy link
Member Author

Choose a reason for hiding this comment

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

I removed the notion of inactive member as it adds complexity instead of clarity as pointed out by Brian.


## Nominating a new member
### Nominating a new member

For someone to become a JupyterLab Council member, they should already be a consistent,
positive, productive member of the community. Newcomers are encouraged to
Expand All @@ -55,8 +61,54 @@ This process takes the following steps:
if they are interested. Don't forget to run them by the {ref}`membership_guidelines`
page to make sure they understand what they're signing up for.

## Membership Maintenance
### Membership Maintenance

Every six months, one currently active member should open an issue in the team-compass repo asking all currently active team members to reply if they still consider themselves active. If not (or no response is given by a team member), it will be assumed that they have gone inactive. This will help keep the active member list up-to-date.
Every six months, a bot will open an issue in the team-compass repo asking all currently active team members to reply within three weeks if they still consider themselves active. If a team member replies no, or does not reply, we will conclude that they are inactive. This will help keep the active member list up to date.
Copy link
Contributor

Choose a reason for hiding this comment

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

This part of the PR is intertwined with the idea of active/inactive. Either someone is on the council and can vote, or they are not and they can't. And if they are not on the council, they can join or rejoin by a vote of the council members. Allowing previous members to rejoin with no vote, creates potentially problematic situations.

Copy link
Contributor

Choose a reason for hiding this comment

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

I do like the idea though of regularly asking council members if they would like to continue to be council members.


Remember, an inactive member can return at any time by simply changing their status on the team-compass page.

## Release team member

### Joining the team

Any JupyterLab Council member can ask to be part of the release team using the weekly call, chat, or official council email list.

### Release team responsibilities

Release team members can manage the following teams:

- GitHub JupyterLab organization: membership of the [release team](https://github.com/orgs/jupyterlab/teams/release)
- PyPI Jupyter organization: manager of the [JupyterLab team](https://pypi.org/manage/organization/jupyter/team/jupyterlab)
- NPM jupyterlab organization: membership of the [jupyterlab team](https://www.npmjs.com/settings/jupyterlab/teams)
fcollonval marked this conversation as resolved.
Show resolved Hide resolved
fcollonval marked this conversation as resolved.
Show resolved Hide resolved
- conda-forge jupyterlab recipe: maintainer rights

> An admin will need to add a new member to all three teams.

Members of these teams have publication rights for major JupyterLab-related packages. Team members can publish a release and can react quickly in case a published package is broken or corrupted.
Copy link
Contributor

Choose a reason for hiding this comment

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

Not sure what "these teams" refers to. Also, this makes it sound like the release team are the only folks who can cut releases. But the language above suggests that the release team only manages the group of people who can cut releases (which is a separate team). Part of the reason we should clarify this is that our different repos in the JupyterLab org often have different groups of people who release them.

Copy link
Member Author

Choose a reason for hiding this comment

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

Wording update for clarification.

I did not mention an explicit list of packages. But the pratical consequence of what is described here is that release team member will be able to release jupyterlab but also jupyterlab-git or the Jupyter renderers as those packages are officially supported as JupyterLab extensions. But it is true that there is a gray area for repository such as jupyterlab-latex, jupyter-ai or jupyterlab-hdf5.


### Membership Maintenance

Every six months, a bot will open an issue in the team-compass repo asking all currently team members to reply within three weeks if they still consider themselves active. If a member replies no, or they do not reply, we will conclude that they are inactive. Inactive members may be removed from their teams.
Copy link
Contributor

Choose a reason for hiding this comment

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

Because we have similar language for other roles, it would be helpful to be specific about which role the current paragraph applies. This could be addressed by changing "current team members" to "current release team members".

Copy link
Member Author

Choose a reason for hiding this comment

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

Clarify this point.


## Admin team member

### Joining the admin team

Any JupyterLab Council member can ask to be part of the admin team using the weekly call, chat, or official council email list. There should be no more than four administrators. If there are four administrators already, consensus should be achieved between the new admin candidate and the existing administrators to determine a new four-person admin team.

> The Software Steering Council representative will automatically be part of this group, in addition to the four members chosen above.

### Admin team responsibilities

Admin team members manage the following teams:

- GitHub JupyterLab organization: [ownership](https://github.com/orgs/jupyterlab)
- PyPI Jupyter organization: manager of the [JupyterLab team](https://pypi.org/manage/organization/jupyter/team/jupyterlab)
- NPM jupyterlab organization: [ownership](https://www.npmjs.com/settings/jupyterlab)
fcollonval marked this conversation as resolved.
Show resolved Hide resolved
fcollonval marked this conversation as resolved.
Show resolved Hide resolved
- conda-forge jupyterlab recipe: maintainer rights

Administrators maintain membership of the teams listed above.

### Membership Maintenance

Every six months, a bot will open an issue in the team-compass repo asking all currently team members to reply within three weeks if they still consider themselves active. If a member says no, or they do not respond, we will conclude that they are inactive. Inactive members may be removed from their teams.
fcollonval marked this conversation as resolved.
Show resolved Hide resolved
4 changes: 3 additions & 1 deletion docs/team/member-guide.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,8 +26,10 @@ maintainers find and choose the right communication channels and have a positive
In this respect, we are using:
1. GitHub issues for specific discussions related to changing a repository's content
(e.g. feature requests, bug reports).
2. The [Discourse forum](http://discourse.jupyter.org/) for general discussions, support
2. The [Discourse forum](https://discourse.jupyter.org/) for general discussions, support
questions, or just as a place where we can inspire each other.
3. The [Gitter channel](https://app.gitter.im/#/room/#jupyterlab_jupyterlab:gitter.im) for discussions and support questions.
fcollonval marked this conversation as resolved.
Show resolved Hide resolved
fcollonval marked this conversation as resolved.
Show resolved Hide resolved
4. The [JupyterLab council mailing list](https://groups.google.com/u/1/g/jupyterlab-council) for discussing membership, none-public questions,... .

## How can I help?

Expand Down