# `jupyterhub-contrib` proposal draft

Notes from meeting facilitated by Sumana: https://hackmd.io/x5LxA5KwQoKvOqbBemU-SA

## Goal

- Frame this as a celebration of JupyterHub's growth and criticalness to the broader ecosystem
- Prior contributors feel celebrated, rather than demoted
- **User expectations** of a particular package's level of support from the JupyterHub core teamm is clearly communicated
- **Maintainer expectations** for what is promised (implicitly or explicitly) on any repo is clearly communicated
- Does **not** tie what it means to be a "JupyterHub contributor" or similar label of belonging and validation to code based contributions on GitHub only.

## Prior art

- [CNCF Graduation criteria](https://github.com/cncf/toc/blob/main/process/graduation_criteria.md)
- [Criteria for getting an extension deployed on Wikimedia servers](https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment)
- [CRAN package acceptance criteria](https://cran.r-project.org/web/packages/policies.html)
- [TideLift Lifter Standards](https://support.tidelift.com/hc/en-us/articles/4406288074260-Lifter-tasks-overview#lifter-tasks-overview-0-0)
- [Non-canonical explanation of PyPI Trove development status classification](https://martin-thoma.com/software-development-stages/)
- [jupyterlab-contrib discussion](https://github.com/jupyterlab/team-compass/issues/52)
- [Debian's `contrib` area](https://www.debian.org/doc/debian-policy/ch-archive.html#the-contrib-archive-area)

# Proposal 1: `jupyterhub-contrib`

## Goal

To provide a centralized space for community members to *collaborate* on JupyterHub adjacent projects in a welcoming and organizationally neutral way, while communicating that the JupyterHub core team itself is not responsible for these projects. We seek the following outcomes:

1. Reduction in duplication of community efforts
2. An easy way for people creating new projects to feel included as part of the JupyterHub community, without necessarily increasing the load on the JupyterHub core team
3. A centrally governed place for projects to grow in, without living in a specific company / organization's space.
4. Have just enough ceremony that bringing a project into `jupyterhub-contrib` is a meaningful marker for the folks involved, but not *so much ceremony* that it takes way too much time. This is also an important marker of differentiation from [jupyterlab-contrib](https://github.com/jupyterlab-contrib/) - it lists no requirements, and has no ceremony, and hence is actually an *unofficial* contrib space. The goal of this proposal is to include *just* enough ceremony to make it an *official* contrib space.

## Criteria for inclusion

https://github.com/cncf/toc/blob/main/process/graduation_criteria.md is a heavy inspiration for this. Note that this is a good match for the *Incubating stage*, *not* the sandbox stage.

### Social criteria

The primary goal here is to ensure that projects here are *vendor neutral* (in terms of who has control) as well as *actively broadly useful*, while communicating that the JupyterHub core team is *not* maintaining them.

- Evidence of active collaboration, requiring at least two active contributors who are *not* from the same organization (broadly defined). If a project originates in one organization, it should seek contributors from a different organization before it can be accepted here. Note this isn't exclusively about *code* contribution, but about establishing that this project isn't exclusively controlled by one vendor or institution.
- Evidence of *use* by two different groups, as broadly defined. This may just be 'intent to use' for early stage projects.
- Clearly documented security response process, with a *prominent* notice that security patches for this project are **not** handled by the JupyterHub core team! Note that it's ok to say that there's no guarantee of a security response, but this must be still explicitly stated.
- The Jupyter CoC applies, and all contributors will be subject to it in *exactly* the same way they would be under the `jupyterhub/` GH org. (Note: This *must* be cleared with whoever is handling CoC reports) (Note: This is also taken from CNCF, where they require CoC adoption even for the sandbox stage)
- The initial (minimum 2) contributors will be granted 'admin' rights on the repo, and and listed on the README. They may invite whoever they wish to the project and manage rights as they see fit. Ideally, as new users get granted rights, they will be mentioned in the README for better visibility.
- JupyterHub core team members *do* automatically get rights (by dint of having rights over the whole org), but there are no expectations on them maintaining any of these projects. This *lack of commitment* shall be prominently displayed in the README alongside current list of actual maintainers. JupyterHub core team members may also be contributors to these projects, but that's done in their individual capacity and does not commit the entire core team to the project.
- While membership in any project under `jupyterhub-contrib` is not *required* to call oneself a "JupyterHub contributor", if you do have membership, you **definitely** are a JupyterHub contributor! Congratulations :) (Note: Make sure this is worded to be *inclusive* and fight imposter syndrome, rather than *exclusive* (you are a contributor only if you have these specific GitHub rights). This intent could be communicated better than the current chosen set of words do)

### Technical criteria

We try to be as minimal here as possible, while trying to make sure
there is *some* consistency across projects here. The goal is for contributors to different `jupyterhub-contri` *and* `jupyterhub` projects to have similar setup experiences.

(Note: I'm not super tied to the specifics here)

(A lot of these can be easily done by starting from the [jupyterhub-python-repo-template](https://github.com/jupyterhub/jupyterhub-python-repo-template), but you don't *have* to do that as long as you meet these standards)

- Uses a `pre-commit.ci` based pre-commit file for ensuring autoformatted code styling and linting. This helps keep everyone on the same page and avoids long conversations about code style. (Editors's note: We can ideally just link to a specific file here and require everyone use that.)
- Has an established release process that any contributor can follow to make releases, present as a `RELEASE.md` file or as a section in the `README.md`.
- Has an established process to get someone set up to contribute to the project, present as a `CONTRIBUTING.md` file or as a section in the `README.md`.
- Licensing matches that of the JupyterHub projects:
- Licensed under 3-BSD (although [an additional OSI approved license](https://github.com/jupyterhub/zero-to-jupyterhub-k8s/blob/main/LICENSE) is acceptable, if this project is at the intersection of two communities that have differing licensing needs)
- Copyright notice, when required, is set to 'Project Jupyter Contributors'
- There is no copyright assignment of any sort - individuals retain copyright to their own contributions. This means no [Contributor License Agreements](https://en.wikipedia.org/wiki/Contributor_License_Agreement)
or similar may be required to contribute to this project.
- Documentation is published via Read The Docs. If there are technical challenges preventing this, GitHub pages is also acceptable.

### Python specific requirements

- For Python based projects, [PyPI Trusted Publisher](https://docs.pypi.org/trusted-publishers/using-a-publisher/) mechanism must be used to avoid relying on specific individuals' PyPI accounts.

## How can a project apply?

- An issue template will be made available in the `jupyterhub/team-compass` repo with appropriate checkboxes for the social & technical requirements
- The process should not take too much time or energy from the core JupyterHub maintainers, but they should have a say in what gets in here. To balance this, the suggested voting process is either 25% unappossed (this means 3 core team members saying 'yes' and nobody saying 'no') over a period of 14 days or a majority vote with 50% quorum requirement if there is any opposition. The majority vote requirement will be initiated if anyone votes No. (Note: We should check with Sumana or someone else with more experience here, so we don't marginalize voices. I am concerned this would make it harder for someone with concerns to say 'no' as that may be perceived as stopping energy)
- Alternatively, we just say it needs approval from 2 JupyterHub core maintainers and that's it. However, especially given we will apply our CoC to this, I'd want there to be a way for folks to say 'no'.
- For CNCF, they require a two-thirds majority for acceptance
- See https://github.com/jupyterlab/team-compass/issues/172 for prior art of sorts here

### Graduation criteria to `jupyterhub`

Sarah: Feel free to tell me this is out of scope right now, but I expect it to come up as a question when we go public.

- Extend the criteria in the "social criteria" section above, e.g.:
- 5 active contributors
- evidence of _use_ by 5 independent groups (intent to use)
- evidence of _use_ by 2 independent groups (documented adoption, or undergoing adoption, i.e., more than intent)

## Plan of Action for Rollout (if adopted)

1. Further wordsmith the proposal as needed and publish on our team-compass site
- Also include application issue template
2. Create the new org and give the core team permissions
- **No repos are automatically moved at this point**
3. Open an issue on each repo briefly describing the change (point to newly minted guidelines) and ask contributors whether they would prefer to stay in jupyterhub or move to jupyterhub-contrib
- can be automated with a script
- some repos can be excluded from this step, e.g., z2jh, jupyterhub, mybinder.org-deploy, team-compass, etc
4. Move consenting repos to jupyterhub-contrib

---

# Proposal 2: `jupyterhub-critical`

Can come later, has very differnet goals to `jupyterhub-contrib`.

---

# Prior drafts

I realized I was trying to make too many proposals at once and tried to narrow scope

## Celebrating JupyterHub's success

JupyterHub work started in May 2014, and the 0.1 release was in March 2015. In the years since, the project has seen wild sucess. It has a ton of users ranging from students encountering any kind of code for the first time to researchers who eventually win nobel prizes. A broad ecosystem has also grown around the initial project, integrating with many other popular projects (like [Kubernetes](https://github.com/jupyterhub/kubespawner))

[insert-more-things-about-jupyterhub-success]

(editor's note: Establish here that JupyterHub's userbase and community has grown, with depth and breadth. These changes are now happening directly as a result of this success)

## Managing User expectations

Given its popularity and criticalness, users have come to expect that projects provided (ed: or 'adopted'?) by the JupyterHub team meet certain production level standards. Some of these user expectations are:

(editor's note: These should be written from the perspective of 'things users expect from jupyterhub team that take time and energy'. 'subject' and 'object' should be clearer)

1. Triaging submitted issues, so bugs are fixed & desired new features may be implemented
2. Code review on submitted pull requests
3. Consistent releases with a clear versioning scheme, with some backwards compatibility guarantees & notes on how to upgrade safely
4. Security review and response
5. Generally useful and adoptable in diverse ways, not tied to a single hyper-specific use case nor company.
6.

Currently, there are 74 repositories in the [jupyterhub](https://github.com/orgs/jupyterhub/repositories) github org. The [core team](https://jupyterhub-team-compass.readthedocs.io/en/latest/team/index.html) is less than a dozen people. We strive to meet these user expectations on all these repos, but reality is that *some repositories are more critical than others*, and maintainer time is often spent proportionally. However, since this is not communicated *explicitly* to end users, there is often stress on the maintainers (editor's note: finish this sentence?!)

This document proposes multiple github organizations, to communicate these expectations to users *and* maintainers more cleanly.

Note - there isn't anyone *specifically paid to work on JupyterHub*, although there are folks who spend some part of their paid time on JupyterHub maintenance. So make no mistake - these are all 'best effort' still.

## The `jupyterhub-critical` GitHub org

Critiera: Popularity, and criticality.

Criticality defined here:


## The `jupyterhub` GitHub org

## The `jupyterhub-contrib` GitHub org