How can community members ASK to join our Contributor/Maintainer team?

[sgibson91]

Context

We have the following webpage which denotes the teams we have in JupyterHub, the responsibilities and expectations of team members, and also criteria for joining:

• https://jupyterhub-team-compass.readthedocs.io/en/latest/team/structure.html#steering-council

The Maintainers and Steering Council teams have very loose process on how someone joins in the "How to Join" sections, mostly around another team member opening an issue or using other channels to recommend someone. Such a process is lacking from the Contributors, I think mostly to keep gatekeeping at a minimum for this level as there is no limit on team size.

I think one process that is missing from all teams is the ability to self-nominate. This means we are relying on maintainers/contributors in the community to notice someone's good work, or someone being brave enough to open an issue/talk to someone else and say "hey, I actually believe I'm meeting these criteria".

We should definitely keep the practice of noticing people's work and rewarding them with an invitation to an appropriate team, because this gives people a sense of belonging. Though I do believe that having a clear process for self-nomination will encourage more people to step up into roles of contributors/maintainers and there's the potential to grow these teams more quickly in that regard.

Proposal

We should develop some lightweight process/issue template for someone to nominate themselves for membership of a given team. This process should collect:

• what team they want to join (maybe a form per team?)
• evidence that they meet the criteria for that team - this can be in the form of links to Discourse and GitHub issues/PRs, etc

Approval process: we probably want to keep this similarly lightweight, but also have different levels based on the teams. Here are some suggestions:

• Contributors: We want to be generous with membership here. If a single maintainer agrees the applicant meets the criteria, they should go ahead and add them to the team.
• Maintainers: Maybe agreement from two maintainers is required here
• Steering Council: Need some quorum from the current steering council members - to be decided

We shouldn't say "no", we should say "not yet"

Applies to all teams.

Getting a rejection is hard and demoralising. We don't want to discourage folk from trying for the first time, or trying again. Therefore I think if the answer is not a "yes", it should be a "not yet". We should respond with which specific criteria we do not think the applicant is meeting and specific advice on how to improve that, we should offer a live chat (audio/video) to discuss the feedback should they wish. And we should respond with encouragement to try again in the future.

Action Points

• Agree/tweak the proposal above as needed
• Develop a process for self-nomination, such as an issue template/form
• Update documentation to explicitly state that we accept self-nominations and how to do that

[manics]

Do you think GitHub Team membership is still the best way to record membership? It's convenient since it's already there, but does it enforce the idea of GitHub privileges = status in the JupyterHub community?

Which then leads to the question.... should it possible to become a contributor without having a GitHub account? I'm unsure on this, I like the idea of separating them, but the reality is GitHub is used as the main communication medium and ultimately people have to sign up to something.

[sgibson91]

Yeah, we operate in GitHub's ecosystem and that means certain social rules are enforced upon us because of how the system is designed. But as you say, we have to exist somewhere.

I'd love for this issue to focus on clearer pathways into the system we've got for now, but I think the point you raised would make a great issue all of its own.