Skip to content

Define a source of truth for where to create project-wide issues that don't have an obvious home #264

@choldgraf

Description

@choldgraf

Jupyter is a big and complex project, with many sub-projects, working groups, etc. It has dozens of repositories, some of which have clearer scope than others. As a result, it is not always clear where to open issues if they don't have a clear repository. As a result, people are doing the best they can, and a pattern I've noticed is to choose one of the following repositories and manually tag @jupyter/executive-council.

I recommend that we define a source of truth for where people should post cross-project issues that don't have an obvious home. That way there's a single place for this kind of conversation rather than asking users to make a best guess. This would reduce the burden on others for finding the right place to create issues, and would also reduce the work needed to find issues that don't have an obvious home.

Proposal: Define a jupyter-team-compass for this

I think that using a "team-compass" for project-level issues, or issues that don't have an obvious home, is a good way to achieve this. It would follow the same team-compass pattern that sub-projects use, which reduces the cognitive load on people. To begin, we could keep this repository simple, using it as a place to track project-wide issues, and noting in the README that documentation about sub-projects and where else to open issues is at the governance docs (jupyter.org/governance).

Considerations to take

I don't think that this repository should have guarantees that the @jupyter/executive-council will respond to or action all issues. That's just not sustainable for a group of volunteers with a lot else on their plate. However I do think the EC should commit to watching this repository and considering whatever happens in it.

Where have people been opening issues instead?

Here's a list of places where people are opening issues without an obvious home:

Related issues

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions