Skip to content

Recommend a way for sub-projects to signal strategically key projects vs. nice-to-haves and prototypes #336

Description

@choldgraf

There's a common point of confusion across many of the subprojects in Jupyter:

  • Each subproject usually has a GitHub organization with a variety of repositories in it.
  • Most of those repositories are internal, one-offs, prototypes, etc. They're owned by the team but without a ton of restrictions or guarantees around them.
  • A subset of repositories make up the "strategic core" of the subproject. They have an extra degree of support and capacity, and more expectations around maintenance, security, accessibility, etc.

We currently don't have a standard way to clarify which repository is which, what extra commitments we make for "strategic core" repositories, or how projects choose what gets this special status. As a result, users are confused about which tools they can rely on for maintenance and stability, and it is harder for maintainers to know where they need to spend their time.

We need to define what 'core' repositories means

What I've heard from others, these ideas have consistently come up. "Core" repositories are those that:

  • Get more strategic thinking about their product direction in general.
  • Get more development and maintenance attention from the team.
  • Adhere to best practices around accessibility and security.
  • Have more rapid response to things like security problems.
  • Generally, are more dependable in the short- and long-term.

We need a way to communicate 'core' repositories for projects

We need a standard way for subprojects to communicate "these repositories are special, they have extra commitments to stability, security, growth, and maintenance".

We need a way to choose 'core' repositories for each subproject

We also need a way for subprojects to choose when to apply this status to projects. It needs to be more selective than "any repository in the subproject github org". Something like a JEP, team compass PR process, etc. For decisions that would impact all of Jupyter, it might need something with more stakeholder discussion and buy-in.

We need a way to ensure the 'core' repositories are properly resourced

These core repositories need more guarantees, which requires resources to meet those guarantees. We need a process that ensures the key repositories in a subproject will have the time and attention they need to meet their goals. Or, we need a way to demote repositories if it's clear they don't have the attention they need to meet user expectations.

Ideas

This is a grab-bag of ideas I've heard:

  • Use a -contrib org. Use orgs like jupyter-book-contrib for repositories that don't have this "extra commitment" status.
  • Use a flag or repo README metadata. Use a badge like Core tool with a link that explains what extra commitments this conveys.
  • Keep a list in the team compass. Ask each subproject to define the subset of repositories that get "special attention" in their team compass so it's obvious for others.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions