Where should Jupyter "plugin" projects live?

[Zsailer]

Background

This is a particularly interesting question for plugins that have components that interact with multiple layers of the Jupyter stack (NBGrader is example).

As an example, a hypothetical plugin might provide:

1. A JupyterLab/Notebook frontend extension
2. A Jupyter Server extension with REST APIs/websockets
3. A JupyterHub-managed "service" that (1) and (2) interact with.

These projects often create their own Github org. I can see some pros/cons with this model:

Pros:

1. Self autonomous
2. Looks more official than a personal Github account
3. Jupyter subprojects/people don't have any explicit responsibility to maintain

Cons:

1. Not clear to users how closely it follows Jupyter core projects; is it trustworthy?
2. Not a clear relationship with Jupyter governance/licensing; presents a challenge for some organizations that might want to contribute, but can't without some explicit relationship to Jupyter
3. Jupyter subproject active members may not have access to maintain if needed.

We have felt some painful effects of the Cons (3) in a few cases.

The Goal

Provide a home for such projects that satisfies the following:

• Gives users confidence that the project aligns closely with Jupyter subprojects and has a future
• Gives outside organizations/companies the ability contribute to these types of projects; shows neutrality, multi-stake holder representation, jupyter aligned, and licensed appropriately.
• In the rare case that a project is abandoned, give Jupyter subproject maintainers the ability to take over or (at the very least) handle the deprecation.

Proposal

I'm proposing we create or find an existing home that eventually satisfies the following conditions:

1. Create an organization to host a collection of "plugin" repositories
2. This organization is not under Jupyter governance; i.e. it is not a subproject and doesn't have an SSC vote.
3. This organization borrows some of the processes outlined by Jupyter's subproject governance model. Specifically, a team membership model, team-compass, and voting mechanism within the org.
4. Anyone can propose a plugin project/repo to be added to the org.
5. The Team votes and accepts/rejects proposals for incoming projects/repos by evaluating them on some set criteria. The stringency of the bar will help determine the "trustworthiness" level for plugins in this org. Here are some initial ideas:
   a. long-term support
   b. active development
   c. Jupyter's BSD-3 license.
6. Team members in this org are comprised mostly of members from Jupyter subproject teams. This has a few benefits:
   a. User confidence: core Jupyter folks are involved in some capacity and evaluated the project for long term support.
   b. Outside organization confidence: contributing is safe, since this org still represents multiple stake holders around Jupyter and projects inherit the Jupyter BSD-3 license.
   c. Future-proof confidence: is the project becomes stale/abandoned, Jupyter folks have the ability to handle next steps.
7. Each repo is autonomous once its inside the org, meaning it can hold its own meetings, call its own votes, and add its own collabators/team members, etc. The only requirement is that the org team members have admin rights on the project, in case there is a future where the project gets abandoned, and the core team needs to do something with it.

[ellisonbg]

@fperez @afshin

We discussed this briefly in the governance meeting on Monday. The main theme in that meeting is that we believe that the project (through the Executive Council and Software Steering Council) should have a clear set of criteria for when something should be part of Jupyter or not (to the extent that Jupyter leaders are the ones making the decisions - obviously, we can't force others to make their code part of Jupyter). We may also want to revisit program such as the Jupyter incubator to make it easier for early stage projects that don't fit clearly into an existing subproject to be formally part of Jupyter.

A couple of related thought that came up:

• The new governance model that is rolling out this fall should relieve a lot of the difficulties in our former governance and decision making model. As a result, we hope that there are fewer downsides of something formally being part of Jupyter.
• In spite the best intentions of everyone, there is confusion about some of these adjacent GitHub orgs/repos (jupyter-lite, jupyterlab-contrib, jupyter book). These projects are built by leaders in the Jupyter community, use Jupyter branding and messaging, etc. This is an issue both from a trademark perspective, but also from the perspective of user/contributors who may be confused about what exactly they are participating in and the governance model of those projects (decision making, Code of Conduct, etc.).
• There are lot of advantages to being official part of Jupyter, hopefully even more so as the new governance model rolls out. We have a Code of Conduct and enforcement mechanism, we have a clear decision making model, we are prioritizing diversity, equity, and inclusion, etc. Furthermore, many corporate-employed contributors only have permission to contribute to actual Jupyter governed subprojects.

At the same time, not everything that Jupyter leaders work on can or should be part of Jupyter. Having specific criteria and mechanisms (Jupyter incubator, etc.) would help all of us work through these questions as new repos/orgs are considered. We encourage anyone that would like to discuss these matters to attend the weekly governance office hours on Monday 10-11 am PT (see the Jupyter calendar here: https://discourse.jupyter.org/t/jupyter-community-calendar/2485).

[Zsailer]

Having specific criteria and mechanisms (Jupyter incubator, etc.) would help all of us work through these questions as new repos/orgs are considered.

❤️

This is great. Maybe we can borrow some ideas from the CNCF who have done a great job defining a clear path from incubation to "graduated" projects in their ecosystem.

Either way, I'll start coming to the EC office hours to develop a plan here. Plugins are a really great way to invite new folks into the community, so I'd love to help make this happen. 😃