Rename "core team" to "JupyterHub council"

[minrk]

As the new Jupyter governance is getting put together, it might be good to have common terms with other Jupyter subprojects.

There is a bootstrapping process, to be called "$Subproject Council". However, we already have an analogous structure in our 'core team', so I don't think we need to bootstrap from scratch. I propose we:

1. rename "core team" to "JupyterHub council" to align with upstream nomenclature
2. Invite everyone on the current core team to the council, to give everyone a chance to opt in or out (we officially are supposed to check-in every year, but haven't actually done that since we decided we should)
3. maybe some links to wider Jupyter governance?

I'm not sure there are any other updates to make.

[choldgraf]

+1 from me - one question is whether we change the structure of "red team", "blue team", "green team". It sounds like the "red+blue" teams would be the council? Or just the red team? (happy to discuss simplifying this if it is too much complexity)

[minrk]

I would be okay with either approach. I think including both makes the most sense right now.

[choldgraf]

I noticed that the jupyter-server team put together a similar "core team" model, but opted to remove the distinction of team color. Instead they just have "active and inactive team members". Some discussion here: jupyter-server/team-compass#5 (comment)

Currently, the "blue" vs. "red" distinction is only defined in the Binder governance docs (not the JupyterHub docs). Moreover, it doesn't seem like we are strongly enforcing the (somewhat implicit) responsibilities and expectations listed in there.

Given that, my feeling is that we should do one of these two things:

• Remove the distinction between team colors, and define a single "council" with a clear set of expectations and responsibilities.
• Sharpen the language around blue and red team membership and expectations, so that they have more meaning that reflects reality.

My feeling is that the first bullet is simplest, since it matches the informal practices that this team follows already (AKA, in practice we do not already make strong distinctions between blue and red, it is more a way for people to signal what kind of stuff they do, and this is also already captured in the "all contributors" emoji people attach to their images).

What do you think?

it might also be helpful to hear from @Zsailer about the rationale behind not using team colors, and how that has worked out for y'all so far!

[manics]

Remove the distinction between team colors, and define a single "council" with a clear set of expectations and responsibilities.

I've got a vague recollection of discussing this in the past, can't remember where, when, or what we decided!

If we get rid of the colours we can still use the emojis (which I only discovered today) to highlight people working on BinderHub.

[choldgraf]

(just a note that if this has already been discussed and decided, I also don't feel very strongly about this, so if we just wanna move forward with @minrk's proposal and keep both colors but lump them under a council, that's fine with me!)

[manics]

It's on the agenda for tomorrow's team meeting.

[damianavila]

I'm not sure there are any other updates to make.

As part of the bootstrapping process, there might be interest from Steering Council members to be part of the Hub Council. Since the core team is already well-formed here, maybe one additional steps would be to invite those SC memebers who are interested.

I think @Carreau might have information about the ones who are interested.

[choldgraf]

We discussed this in the March 2022 meeting. I think that the general idea was "yes, it's fine to re-define as council, but we also need a way to give people permissions in the repositories without such a high barrier to entry".

So to move this forward I'd like to make a proposal and see what folks think:

Proposal

Define 4 groups of people in the JupyterHub team, partially inspired by Matt Rocklin's definition of being a maintainer:

• The JupyterHub Team: Any person that has commit rights to at least one repository in the jupyterhub/ organization. These people are expected to abide by the Code of Conduct and generally do what they can to support the project. Team members are added by Maintainers. Have write permissions to repositories.
• Maintainers: A subset of the JupyterHub Team. Commits to spending a significant amount of their open source time watching issues, responding to them and getting them to an actionable state, and reviewing PRs in one or more repositories. Are expected to put extra effort into building a healthy, productive, friendly community dynamic. Have admin permissions to repositories they agree to maintain. (This is roughly the blue team)
• Steering Council: A subset of Maintainers. Commits to overseeing the strategic vision and success of JupyterHub as a whole. They have tie-breaking authority for any decisions where we cannot reach informal consensus. They also agree to actively look for ways to improve the JupyterHub community thrive. They represent JupyterHub to the broader Jupyter community. (This is roughly the red team)

and a special "working group"-style team:

• mybinder.org Site Reliability Team: A special group of people that dedicate their time to supporting the live infrastructure in one of the mybinder.org federation deployments. They have decision-rights over whatever happens on mybinder.org, though the Steering Council is expected to provide them support on major sustainability and strategy questions.

[manics]

I think this is a good start, and represents the current setup.

However I think in future it'd be nice if we could move away from using GitHub privileges as a mark of status within JupyterHub for a couple of reasons:

• There's more to running JupyterHub than your activities on GitHub, or coding
• From a security perspective it's best to only hand out privileges as required for the tasks being done, and not as a mark of status

The ideal situation would be a structure that supports having someone on the JupyterHub Steering Council with no GitHub write access at all, for example a community manager.

However since that's not the case at the moment I've got no objection to going with your current proposal now, then adapting the it later after we've had more time to think. One easy change could be to say The JupyterHub Team is anyone with membership of the JupyterHub GitHub orgnisation. If we change the default privileges of org members to read-only, then there are no concerns about people having write access to any/other repos. This for example allows us to add issue triagers to individual repos without giving push access, or if we have a future team member who won't be interacting with GitHub they can have a account with no write privileges.

[choldgraf]

I'd be fine just defining teams in the GitHub org and using that as the definition of team membership. The main reason I mentioned GH permissions above was to make explicit what privileges should come with various team memberships.

[betatim]

I'm fine with #497 (comment).

The way I understand it is that the three levels (team member, maintainer, SC) represent a hierarchy that a person can climb? You start out as a JH team member and over time and with interest and effort you could become a SC member?

Why special case the mybinder.org people? Aren't they "just" maintainers of the mybinder.org-deploy repo? From the description of the maintainer role it sounds like it is what I'd expect you to do when helping run mybinder.org.

Could you clarify what the difference is between a JH Team member and a Maintainer? Asked differently, if not helping to maintain one or more repositories what does a JH Team member do/what do I have to do to become one?

[minrk]

I think that's a great proposal.

Why special case the mybinder.org people?

Unlike everything else, this team operates a service. If we operated other services, it might make sense for additional teams.

Could you clarify what the difference is between a JH Team member and a Maintainer?

I think it's about commitment/expectations. Lowering the bar for commit rights to not necessarily imply putting in a certain amount of time. Maintainers are expected to be available to a certain degree, whereas 'members' may not.

I do think it's a useful question to ask, because we often fall into de facto maintainers, and there may not be an obvious time to transition someone across this boundary.

[choldgraf]

The way I understand it is that the three levels (team member, maintainer, SC) represent a hierarchy that a person can climb?

Yep - they should have increasing levels of responsibility and privilege, and an increasing bar to attain.

Why special case the mybinder.org people?

Good question - I wasn't sure on this either. My quick thought is that operating, paying for, and running a live service has a different set of expectations than a typical open source maintainer role, which is why I imagined giving those people credit specifically for that extra work.

Could you clarify what the difference is between a JH Team member and a Maintainer?

I think it's about commitment/expectations. Lowering the bar for commit rights to not necessarily imply putting in a certain amount of time. Maintainers are expected to be available to a certain degree, whereas 'members' may not.

Yep exactly. I didn't want "would you like commit rights to this repository?" to also require "are you willing to serve in a maintainer role for this repository?" because the latter seems like a much higher bar to ask of somebody, and the former is useful just to provide extra fluidity and keep things moving along.

In my mind, you'd first get commit rights to a repo by asking or someone offering, and as long as you meet a minimum bar of trust we should be willing to do this. That makes you a team member and you can now merge PRs.

Over time, if you are a regular contributor that reviews, engages in issues, and potentially merges PRs yourself, then you may gain the status of "maintainer" which gives you the ability to add/remove other people, and perhaps a higher degree of responsibility and prestige as well.

Another reason for this is that "emeritus" maintainers are no longer maintainers, but I'd still like to consider them "team members" :-)

[betatim]

Thanks for the clarifications.

Maybe we can add examples of things you can do to be a team member. For example triaging issues, responding to issues and helping out on the forum.

Depending on the repository (mostly how mature/old/widely used it is) I have different feelings about having people merge changes without also having signed up to maintaining the repository as a whole. This is mostly tied to me thinking of a maintainer as the person who performs all the important tasks that are required for the contribution experience to be great. Mostly because these aren't tasks people choose to work on if they are (casual) contributors.

So I think I support making our levels as much as possible independent of repository access rights (the "can commit" test seems incredibly out of date/old school, from back when people still believed that committing code was 99% of what it took to create a successful project). Instead describing what you can do in terms of tasks/responsibilities across all the places the JupyterHub Team is active (eg the forum has no "commit bit").

[choldgraf]

That is a good point! Hmm maybe we can brainstorm some examples (3 or so) for each? I could make a team compass PR and we can iterate on language there?

[choldgraf]

Update: draft PR

Hey all - I gave a shot at updating some of these docs over in this PR:

• Update team membership docs and refactor #517

It has a lot of changes in there because I ran into some docs roadbumps that I fixed along the way as well. I've tried to explain in that PR where the major areas to look are...happy to iterate there if folks like

[minrk]

Thanks @choldgraf for updating the descriptions!

I think the next step is to send the invitations to re-establish membership. Here's a draft text we could send to all team members listed here:

Dear JupyterHub team member,

As part of the larger Jupyter governance reorganization, we are updating the JupyterHub team structure and membership.
We haven't checked in on continuing active membership as we had originally decided to do, so we are checking in now.
Please respond to this email with your preferred status (for more information on each role, see here):

• Council member
• Maintainer
• Team member
• Inactive member

If we don't receive a response by X DATE, we will list you as an Inactive member, and you are always welcome to re-join an active team.

Thank you,

• JupyterHub team

(edits welcome)

We could also use different text for folks we believe to be inactive already, if people think that's appropriate.

[manics]

Sounds fine to me, though could probably just use a GitHub issue and only follow-up non-responding individuals?

[minrk]

Good point.

[minrk]

I'll open that Issue today. Can we say 1 week+, so next Tuesday as a deadline? I can send an email to folks who haven't responded by Friday.

[damianavila]

As part of the bootstrapping process, there might be interest from Steering Council members to be part of the Hub Council. Since the core team is already well-formed here, maybe one additional steps would be to invite those SC members who are interested.

Sorry for quoting myself here, but I do not see in #566 people interested to be bootstrapped from the current Jupyter SC actually being bootstrapped as suggested by the governance document linked at the top comment. Could that be the case?

[minrk]

@damianavila Sorry, I missed that comment the first time. Since we already have teams and governance, I don't believe the bootstrapping process applies except as a reference (there's no initial team to seed because we already have a team). I'm sending an email to the SC. I'm happy to nominate SC members, but I think they should be approved by the existing team first.

[damianavila]

but I think they should be approved by the existing team first.

For sure!
I was mentioning this because I think there might be some expectations from some Jupyter SC members to be in the JHub SC as part of the bootstrap process (obviously, after approval of the existing team), although I might be wrong about it.
Thanks for sending the email to the Jupyter SC!

[minrk]

I think our council is updated (PR coming momentarily). There's still more to do after #566 because we haven't explicitly specified membership of any other teams.

• I think it makes sense for folks to be council members but not maintainers, which means we need to specify who's doing both, and check our expectations in the team descriptions if folks agree that matches
• by the new, expanded definition of 'team members' and/or maintainers, I believe we have more team members not currently recognized on this page. For example, these folks have permissions on at least one repo (some should be recognized as team members, some probably don't need access anymore):

dockerspawner
  carolynvs: write
  ssanderson: write
  richafrank: write
kubespawner
  lresende: write
ldapauthenticator
  dhirschfeld: write
jupyterhub-deploy-docker
  jtyberg: write
jupyterlab-hub
  blink1073: admin
jupyter-server-proxy
  bollwyvl: write
  ian-r-rose: write
firstuseauthenticator
  willirath: write
zero-to-jupyterhub-k8s
  aculich: write
  jupyterhub-bot: write
binderhub
  freeman-lab: write
  bitnik: write
  jupyterhub-bot: write
repo2docker
  SylvainCorlay: write
mybinder.org-deploy
  jupyterhub-bot: write
ltiauthenticator
  jgwerner: write
  samhinshaw: write
the-littlest-jupyterhub
  willirath: write
  leportella: write
research-facilities
  rcthomas: write
  tacaswell: write
  stuartcampbell: write
  zonca: write
  cmd-ntrf: write
  scanon: write
  guifrecuni: write
  danielballan: admin
  athornton: write
  fangohr: admin
  mrakitin: write
  awalter-bnl: write
nativeauthenticator
  lambdaTotoro: admin
  leportella: admin
simpervisor
  tdhopper: write
repo2docker-action
  neovintage: write
  hamelsmu: admin
action-major-minor-tag-calculator
  jburel: write
docker-image-cleaner
  jupyterhub-bot: write
nbgitpuller-downloader-googledrive
  sean-morris: write
nbgitpuller-downloader-dropbox
  sean-morris: write
nbgitpuller-downloader-generic-web
  sean-morris: write
nbgitpuller-downloader-plugins
  sean-morris: admin

And these folks are on jupyterhub github org (some on teams, some not) without being on the currently listed team members page:

NAME: [TEAMS]
callummole: mybinder.org operators
captainsafia: Binder Team
ellisonbg: Designers, JupyterHubTeam
fperez: 
henchc: mybinder.org operators
jagwar: mybinder.org operators
JamiesHQ: 
jcrist: 
jhamrick: JupyterHubTeam
jupyter-docker-hub-builder: JupyterDockerHubService
mael-le-gal: mybinder.org operators
mbmilligan: 
parente: JupyterDockerHubService, JupyterHubTeam
rgbkrk: 
ryanlovett: 
takluyver: