search

jupyterhub / team-compass

A repository for team interaction, syncing, and handling meeting notes across the JupyterHub ecosystem.
http://jupyterhub-team-compass.readthedocs.io
62 stars 33 forks source link

Rename "core team" to "JupyterHub council" #497

Open minrk opened 2 years ago

minrk commented 2 years ago

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 commented 2 years ago

+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 commented 2 years ago

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

choldgraf commented 2 years ago

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: https://github.com/jupyter-server/team-compass/issues/5#issuecomment-1006779628

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:

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 commented 2 years ago

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 commented 2 years ago

(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 commented 2 years ago

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

damianavila commented 2 years ago

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 commented 2 years ago

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:

and a special "working group"-style team:

manics commented 2 years ago

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:

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 commented 2 years ago

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 commented 2 years ago

I'm fine with https://github.com/jupyterhub/team-compass/issues/497#issuecomment-1106635594.

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Update: draft PR

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

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 commented 2 years ago

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 commented 2 years ago

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

minrk commented 2 years ago

Good point.

minrk commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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.

``` 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: