How to handle repos that contribute to JupyterHub ecosystem?

[rcthomas]

At the monthly Hub call today, I mentioned that I was interested in contributing a Hub service to the JupyterHub org. This prompted a question: How should such contributions be handled? Options briefly discussed:

• Create another org like jupyterhub-contrib, like jupyterlab-contrib that is for gathering together useful JupyterLab extensions and tools maintained by volunteers. This would be another org to manage.
• Use topic labels or tags to group/classify repos together. For instance, I would transfer my repo to the JupyterHub org and it would be labeled with a "services" topic, maybe also a "contrib" topic to help folks identify the repos of interest

This issue is to provide folks a space to discuss the pros/cons of the options (and other options)

[choldgraf]

I haven't used the notion of repo labels before, but I feel like if we could provide a natural "extension point" for repos with a single org, this would be simpler

[manics]

Can topics be used to filter repos in a single org? The topic links seem to be global across GitHub.

A benefit of a separate org is we can host experimental repos, or projects where we're not sure if we want to support long term.

[minrk]

I think we've tried to keep a pretty low bar for adopting things into the JupyterHub org. This creates the issue that presence on the org may communicate a level of official-ness / maturity / support that is not actually uniform across the org. I happen to think that's a good thing, but recognize the communication problem it creates. If we can communicate that info with labels, I think it's simpler to have fewer orgs (permissions, etc.), but if a separate org is the best way to communicate that, that's okay by me, too.

[choldgraf]

What if we defined a special kind of "core" repository and explicitly listing them in our team compass, and maybe the README of projects.

Core repositories

• Have higher standards for maintainability, stability, bus factor, etc.
• Have the largest user-bases and/or are a crucial part of JupyterHub's functionality.
• Have at least two dedicated maintainers, a clear scope and vision, and no large expected changes in functionality
• Adopt higher standards around inclusive discussion, code review, and decision-making (e.g. we shouldn't have one person unilaterally pushing lots of code...I don't think we need to be too specific in defining this though)

All other repositories are relevant-enough to JupyterHub's mission to be inside of the JupyterHub org, but do not meet the criteria for "core repository" and thus have a much more loose set of expectations around them other than abiding by our code of conduct and general team processes.

[manics]

I think the main downside of having repos with differing maintenance status in the same org is it's difficult to quickly know what it's status is. Topic labels are good for discovering repositories, but not so good for providing metadata about a given repository. We can add statements in the README, but I suspect that's still unclear to someone finding a repo for the first time, since every open-source project has a different definition of maintained/unmaintained. Having one other org makes the distinction a lot clearer.

I like the idea of the above requirements for Core repositories.

[manics]

Prompted by @consideRatio in #621 (comment) I'd like to make a concrete proposal:

• Create a new GitHub org jupyterhub-contrib
• Initial owners are the same as the JupyterHub org
• We migrate any projects we think are appropriate that are already mentioned in various JupyterHub issues without need for further discussion unless there's a clear objection
• We don't require these initial added repos to initially conform to our usual standards/labelling/etc

Following this initial setup we may want to discuss:

• Additional owners or other people with privileges
• Who can be a member of the org
• Prerequisites (if any) for adding a repo
• Process for adding a repo

Are these additional points a blocker for the initial org creation?

If at a later date we decide we don't want two organisations it's easy enough to move repos.

[consideRatio]

@manics I think that sounds fine and think its good that its considered what we do if we don't think this is a good approach after all!

[manics]

I think jupyterhub/oauthenticator#459 (comment) is a good use-case for jupyterhub-contrib. It's a new pending authenticator which should be useful, but is still under development.

[sgibson91]

Hi! We just had a discussion with an external facilitator covering this topic. You can read the notes here: https://hackmd.io/@sgibson91/HJitFKNga

[krassowski]

Hello, I came here from betatim/vscode-binder#33 and would love to revive this discussion. Here is some experience I can share from helping to run jupyterlab-contrib:

Min: 1st order prob: repos at variety of expectations within JH org currently. Need to communicate mult levels of expectations clearly. Not currently being done!

We use status badges for it. For example jupyterlab-vim and jupyterlab-spellchecker have "ready" status, while some other extensions have "draft" status.

Ready	Draft

This is documented on https://jupyterlab-contrib.github.io/index.html

guidelines/criteria: what it means for a repo to be [here] vs [there], tie to maintenance levels? people who are committed over a period of time? + pathway for things to go from one to the other AND VICE VERSA

jupyterlab-contrib has a set of issue templates which I find empowering in a sense - it sets clear steps to becoming a maintainer or moving your own repo into the org, if you are logged in you will see them here:

• "Become a contributor": Become a member of this organization and contributor of a project.
• "Change user rights or project settings": Request changes in user rights or project settings
• "Help with maintenance": Request access to a repository to maintain it.
• "Transfer repository to this organization": Request to transfer a repository you own to this organization

There is also some docs on https://jupyterlab-contrib.github.io/contributing.html

important for people contributing to JH-contrib stuff to FEEL as much as possible equals to people in JH [main]

A small thing that you can do is ensure that core contributors display the membership to JH-contrib on their profiles (because by default membership is private; by making it public you are showing that you are proud to be a member, or at least do not want to hide it).

Prerequisites (if any) for adding a repo

For reference for jlab-contrib this is:

Target

// Write a short description of the feature(s) the repository is providing

// Provide here the URLs to:

• The code repository:
• The npm package on npmjs.com (if available):
• The python package on pypi.org (if available):
• The conda-forge recipe on https://github.com/conda-forge (if available):
• The documentation website (if available):

Reason

// Describe the reason(s) you want to transfer the repository to this organization

Checklist

// Check carefully each points in the following list and mark the fulfilled points.
// If mandatory points are not fulfilled, there is a low chance the transfer will be agreed on.

• You are owner of the repository you want to transfer
• Which role do you want to have in the jupyterlab-contrib organization (check one of):
  • Help with all jupyterlab-contrib repositories
  • Help with the transferred repository only
  • I don't have time anymore to keep helping the project
• The transferred repository (check one of):
  • Must keep the extension name
  • Cannot use the original name
  • I don't care
• The code is available under a Open Source license
• A license file is present in the code repository
• The extension is working on at least JupyterLab 2.x
• The repository contains a README file describing:
  • The provided feature(s)
  • A picture illustrating the feature(s)
  • The available options/settings (if applicable)
  • How to install the extension
  • optional a Binder link to test the feature online
• optional The frontend code (Typescript/Javascript) is tested
• optional The backend code (Python) is tested
• I certify the extension is not using exclusively paid-plan of any commercial service
• I will help the transfer process on the code repository AND the built packages

You must enable two-factor authentication on GitHub