Add policy for membership #206
Conversation
docs/team/becoming-member.md
Outdated
|
|
||
| ### Joining the admin | ||
|
|
||
| Any JupyterLab Council member can ask to be part of the admin team using the weekly call or the chat. If the number of administrators has reached 4 people; consensus should be achieved between the interestee and the existing administrators to get the new 4-people team. |
There was a problem hiding this comment.
I would suggest 6 people as the limit rather than 4, to make sure that there is someone available when it is needed, and to add some members of the EC, for example, as a backstop.
There was a problem hiding this comment.
@jasongrout you mean 6 people including the SSC representative or 6 + the SSC representative?
Co-authored-by: Jason Grout <jasongrout@users.noreply.github.com> Co-authored-by: Jason Weill <93281816+JasonWeill@users.noreply.github.com>
Co-authored-by: Jason Weill <93281816+JasonWeill@users.noreply.github.com>
docs/team/becoming-member.md
Outdated
|
|
||
| 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**. |
There was a problem hiding this comment.
I think we should remove this as it creates ambiguity about who can vote and how one moves between being active/inactive.
docs/team/becoming-member.md
Outdated
| @@ -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. | |||
There was a problem hiding this comment.
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:
- Annual vote participation is set at 2/3. Someone can easily miss votes when they are on vacation without consequence.
- 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.
There was a problem hiding this comment.
I removed the notion of inactive member as it adds complexity instead of clarity as pointed out by Brian.
docs/team/becoming-member.md
Outdated
|
|
||
| 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I do like the idea though of regularly asking council members if they would like to continue to be council members.
docs/team/becoming-member.md
Outdated
|
|
||
| ### 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. |
There was a problem hiding this comment.
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".
docs/team/becoming-member.md
Outdated
|
|
||
| > 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
Thanks @ellisonbg for bringing your suggestions. I agree that removing the inactive status of JupyterLab council membership makes sense. I want to highlight that in this comment for others to voice for or against it.
|
Vote will take place in the private council repo for security reasons
|
Thanks to @fcollonval being insistent about bringing this up during JupyterLab calls; this kept getting moved to the bottom of my list. I appreciate the reminders. Most of this is roughly what I expected based on prior discussions, but I do have questions about what happens with removed council members. I assume they are removed from the GitHub organization and the mailing list and the like. Does being removed do anything else? Like disqualify them from rejoining again after or in the future? Please let me know if these are out of scope and/or detailed elsewhere. |
|
Thanks for the questions @isabela-pf
If a JupyterLab council member steps down (or is assumed too by lack of response when solicited), indeed it will be remove from the GitHub organization team and the mailing list.
No (except if the member was also part of the smaller sub group with additional rights on PyPI and NPM for example).
No, they can ask to rejoin at any time. But the new application will go trough a vote like any new members.
I can clarify that point in the document. I don't recall seeing that any where else. |
fcollonval
added
the
seeking consensus
fcollonval
added
vote
and removed
seeking consensus
Co-authored-by: Michał Krassowski <5832902+krassowski@users.noreply.github.com>
|
I pushed up some typo fixes, 👍 |
|
Thanks a lot for all comments and for voting. The changes have passed with 18 Yes and 3 unexpressed vote. |
|
Congrats on your first merged pull request in this project! 🎉 |
Fix #204
As the discussion has stopped implying informal consensus, I call for a vote on this proposal as mentioned yesterday at the weekly call.
The question to vote on: do you agree with the new membership policy?
The vote will be closed on September 21st at midnight anywhere on earth (or as soon as we reach majority).
The vote: