Help support by increasing the maintainer list

[fcollonval]

nbdime is an important Jupyter project. But we need to be able to iterate faster (at least on the dev branch) on maintenance and small bug fixes. This is in particular highlighted by the migration to Lumino 2 / Lab 4 PR. It would benefit from being merged early to allow all interested stakeholders (here or through jupyterlab-git) to help push large maintenance faster.

At a more generic level, Jupyter projects should have a list of multiple active maintainers with elevated rights on GitHub, PyPI,... . And although best efforts are done (special thanks to @vidartf) in this Jupyter project as so many others, the reality shows that community members with time and knowledge to help supporting this project (special thanks to @krassowski and @Carreau) are blocked by platform rights.
Also I think this project could benefit from being transferred under the governance of the Jupyter Foundations / Jupyter Standards (they are about to be merged) subproject or JupyterLab subproject (less appropriate I guess).

Therefore, I propose to add more maintainers to nbdime on GitHub and possibly on PyPI and NPM (especially as I see only Vidar has rights on NPM). I have in mind: @krassowski, @JasonWeil (or one of his colleagues) and me (or one of my colleagues).

What do you all think?

cc @JohanMabille @afshin @jtpio @dlqqq

[krassowski]

I would add that it would be of great value to merge the JupyterLab 4.0 PR soon (in my view it is very close to merge-able state) and release an alpha or beta version to allow for wider testing, just because of the extend of transition and to gather feedback from community. It might be useful to also include #639 in the pre-release.

[vidartf]

Thanks for this issue. Addressing each point separately:

1. We should have more people with right on this repo. I agree. Up to know, it has mostly been me and @minrk running this repo. We should expand that list, especially ensuring that we increase the bus-factor for access to package repos (thanks for pointing that out!).

2. This is in particular highlighted by the migration to Lumino 2 / Lab 4 PR. Yes, sorry, that PR came out of draft right after I started a two week vacation. That said, this PR basically went from 0 to 100 in that one week. Is there a deadline coming up? Note: I previously offered to help out with that PR (in a lab or server weekly call I think), but was told by Sylvain that "it was under control", so I've held off on looking at that PR while it was in draft.

3. I think this project could benefit from being transferred under the governance of [...] nbdime is currently in the list of projects that are explicitly not represented on the SSC: http://jupyter.org/governance/list_of_subprojects.html#official-subprojects-without-ssc-representation. What are the arguments for changing that?

[vidartf]

I would add that it would be of great value to merge the JupyterLab 4.0 PR soon (in my view it is very close to merge-able state) and release an alpha or beta version to allow for wider testing, just because of the extend of transition and to gather feedback from community. It might be useful to also include #639 in the pre-release.

Note, we might want to backport / forwardport #639 to a lab 3.x compatible version.

[fcollonval]

1. _We should have more people with right on this repo_. I agree. Up to know, it has mostly been me and @minrk running this repo. We should expand that list, especially ensuring that we increase the bus-factor for access to package repos (thanks for pointing that out!).

How would like to proceed with that? Opening a specific issue and advertising about it on discourse and various Jupyter call?

2. _This is in particular highlighted by the migration to Lumino 2 / Lab 4 PR._ Yes, sorry, that PR came out of draft right after I started a two week vacation. That said, this PR basically went from 0 to 100 in that one week. Is there a deadline coming up? Note: I previously offered to help out with that PR (in a lab or server weekly call I think), but was told by Sylvain that "it was under control", so I've held off on looking at that PR while it was in draft.

I apologize that the ball started rolling faster during your vacation. Ideally we would like to get it merge next week.

Thanks a lot for proposing your help; I'm sorry that I don't recall about it before this. I used that PR as an example about repository maintenance; because if it was not for admin rights, the base PR would have likely been merged early (in the main branch or a dev one) to avoid opening PR against the PR from additional contributors and to publish pre-releases to ease testing. And low-value actions could have be shared between maintainers.

3. _I think this project could benefit from being transferred under the governance of [...]_  nbdime is currently in the list of projects that are _explicitly_ not represented on the SSC: http://jupyter.org/governance/list_of_subprojects.html#official-subprojects-without-ssc-representation. What are the arguments for changing that?

I see this as a proposal to increase documentation/communication about governance of this project to help interested party reach out in a proper way if they want to increase their involvements. Hooking up on the governance and communication channel(s) of an existing subproject sounds easier than creating a specific one for this project.

Note, we might want to backport / forwardport #639 to a lab 3.x compatible version.

I get a question about Lab 3 compatibility. Would it answered that need if the webapp is on Lab 4 only but the lab extension support both Lab 3 and Lab 4 (but using CM6 for both)? I think it is possible.

[Carreau]

No objections to add people.

It seem I have the permissions to add maintainers both here and on PyPI (we can also look at trusted publisher and moving the package to the Jupyter PyPI org).

Just let me know.

[fcollonval]

@Carreau if you could grant me the right, I would really appreciate that to make a pre-release.

Adding the package to the Jupyter org and the trusted publisher sounds pretty good. But I can help with that if you don't have much time for that (as I guess switching to jupyter_releaser would also be beneficial).

@vidartf would you be able to grant me rights on npm? Or I get give you rights to the jupyter organization on NPM, so you can add it there.

A release on NPM is needed to start working on jupyterlab-git port - in particular it will be good if we could share more code with nbdime for the diff and merge viewers for plain text files.

[Carreau]

if you could grant me the right, I would really appreciate that to make a pre-release.

Done on GH and PyPI.

Also increased @vidartf permissions as well.

[fcollonval]

As discussed at yesterday lab call, I sent invitation for NPM jupyter organization to Mike and Vidar.

@vidartf could you ping me when you accepted the invitation as I'll need to increase your rights (it is not possible to grant you directly proper rights) for you to add nbdime package through that page:
https://www.npmjs.com/settings/jupyter/teams/team/developers/access

[fcollonval]

@vidartf I increased your rights on NPM - you should now be able to add nbdime to the organization using the above link.

[fcollonval]

Friendly ping to @vidartf would you mind adding nbdime NPM packages to the jupyter organization using the above link?

[vidartf]

@fcollonval Sorry, I thought I had done that already. I tried again. Can you confirm whether it has gone through correctly?

[fcollonval]

Thanks @vidartf I can confirm the package has been added. Closing this issue.

[fcollonval]

Hey @vidartf sorry to ping you again. I forgot about the nbdime-jupyterlab package. Would you mind adding it too to the NPM Jupyter organization?

[vidartf]

@fcollonval good catch, should be added as well now!