[DISCUSS] How to improve supportability of the repo?

[kevin-bates]

Being relatively new to open source, I suspect this is the natural evolution of a project, but I find myself not knowing who to ping specifically for issues or pull request reviews after those items have gone unattended for a certain period of time. This lack of response leads to frustration in the community.

Having a list of active participants, combined with their areas of expertise (or willingness to help) would go a long way in helping the community - as well as current maintainers.

Is this the best approach?
Are there other measures we can take?

P.S., Please know that this is not intended to disparage existing maintainers in any manner. Everyone has other items on their plate and other areas of focus and, in many cases, it's just not practical to maintain areas that are no longer germane to everyday tasks.

[jasongrout]

I agree, it would be nice to have a better idea of who is willing to actively engage in the project, and provide closure for those that have actively maintained it in the past but no longer plan to be involved in day-to-day tasks.

As for me, I can help advise on occasion, but I've really shifted my focus and time to JupyterLab over the last few years.

[Zsailer]

@kevin-bates and @jasongrout, I've pinned this issue, because I think this is important messaging.

Jupyter maintainers treat Notebook like it's near end-of-life, but we haven't communicated that publically. Realistically, the Notebook is still heavily used and needs maintainers, so having some maintainers here is likely necessary.

Moving forward, we need to answer the question, what is the status of Jupyter Notebook repo:

1. actively maintained—accepting features; needs established team of reviewers and maintainers
2. maintenance-only mode—only accepting bug fixes; also needs established team of reviewers and maintainers (but likely less people). We would, then, close all PRs that try to add features with appropriate messaging.
3. end-of-life—archive the notebook repo and redirect people to other Jupyter projects like nteract, lab, etc.

[willingc]

@kevin-bates You raise an important issue. @Zsailer A decision and communication would be a good next step. Maintenance mode with a clear EOL date would be reasonable next steps. Thanks for taking this up in the Jupyter Server meeting.

[Zsailer]

@blink1073, @afshin, @kevin-bates and I met today to knock out some PRs. We also put together a plan to improve the maintenance situation here in the notebook repo.

Action items:

• Host Zoom meeting 30 minutes before JupyterLab Team Meetings to review Notebook PRs (Zach)
• Use last 15 minutes of jupyter_server Zoom meeting to review Notebook PRs (Zach)
• Add the above two meetings to Notebook README.
• Get docs to build (Steve)
• Add language to ISSUE+PR templates and README (Darian)
  • discourage changes that add features to notebook frontend.
  • to redirect server changes to jupyter_server
  • discourse link for help
• Github Actions for tests? (Zach will explore)
• Binder links for PRs.
• Issue closing bot.

[blink1073]

For Github actions, a simple workflow is in the 2.x branch of JupyterLab:

https://github.com/jupyterlab/jupyterlab/blob/2.1.x/.github/workflows/tests.yml
https://github.com/jupyterlab/jupyterlab/blob/3ce3b9f90bf461e3ec15787ae97b0dbdfca31144/scripts/ci_script.sh#L47

[ellisonbg]

One of the important aspects of this is to identify a small subset of issues that are important for us to address at some point (in lab or notebook, which is a separate question). We have a treasure trove of input from users that we don't want to ignore ;-)

One of the ways that I have been exploring these questions is through GitHub's barely-documented issue "interactions" (an interaction is either a comment or reaction). You can't sort issues by the number of interactions, but you can search issues to screen out issues with more than a certain number of interactions. For example, here is all the open issues with more than 40 interactions:

https://github.com/jupyter/notebook/issues?q=is%3Aissue+interactions%3A%3E40+is%3Aopen

This provides a nice overview of the things are users care deeply about.

[Zsailer]

Working document for notebook issue responses: https://hackmd.io/gjzO7Tl0RE2GfRknGYqgbw

[Zsailer]

Add a reference to jupyter-security mailing list.

[kevin-bates]

FYI, notebook tests are passing against traitlets master (i.e., 5.0).

[blink1073]

cc @Carreau. Thanks @kevin-bates!

[kevin-bates]

Regarding the security mailing list, looks like a link into the docs would be sufficient for now: https://jupyter-notebook.readthedocs.io/en/stable/security.html#reporting-security-issues

[Carreau]

One way to "help" is via bots, one of the things I enabled on IPython/ipython is to give a subset of permission to all users via MeeseeksBot, all user can close issues, and add tags even if they are not maintainers – they usually just can't push code.

Usually in the readme you can also list who has which knowledge; but that can also get out of sync.

[Zsailer]

Hey all, I need to miss tomorrow's (7/22) Notebook meeting. I'll catch up with everyone during the Jupyter Server meeting on Thursday (7/23). Have a great Wednesday!

[Zsailer]

Closing in favor of #6210

[kevin-bates]

I don't know where to make such an "announcement", but I need to step away from my maintainer responsibilities (FWIW) for this repository effective January 1, 2022. I will continue to respond to anything in which I'm referenced directly.