Request to Decrease the number of Jupyter Orgs.

[Carreau]

Hi,

As of this morning I had to audit "all" the Jupyter organization for access and or update each organisation/team/repo accordingly if needs be. I'm going to keep the what/why private for good reason, but I'm happy to share why in private channel.

I was able to audit 9 organisations, though I believe we have more (my memory tells me 13).

It is extremely painful to make the audits, and to be sure I did the audit correctly.

I am once again going to ask for a consolidation of organisations. More than a couple of organization is not manageable from a security perspective.

[Carreau]

2 (3?) easy organisations to reduce.

1) Jupyter-attic: Github Now has the "archiving" feature. I suggest to move all repos from jupyter-attic back to Jupyter and use the archiving feature.

2) Jupyter-incubator has only 4 repository. I think the benefit of having an org for that is limited.

3) (?) https://github.com/jupyter-standard has a single repository. I don't see whay it can't be a team under the Jupyter org

I'm guessing already having a list of these orgs would help.

As for the other issue, I understand that it may take time to reply, but please at least acknowledge reception.

[blink1073]

Hi @Carreau, I agree that there are too many orgs (speaking for myself not the EC). To give a concrete proposal to kick things off:

• jupyter is related to backend, standards and meta-content
  • subsumes parts of jupyter-server org
• jupyter-frontend includes frontend applications
  • subsumes jupyterlab, jupyter-widgets, voila-dashboards, jupyterlab-lsp org and parts of jupyter-server and jupyter
• jupyter-kernels
  • subsumes - xeus-kernels and ipykernel
• jupyterhub - stays as-is
• ipython - stays as-is

Note that the above would require a change in governance, and clear standards of onboarding and offboarding repos onto those orgs, as well as org ownership.

[Carreau]

Thanks @blink1073, One question I have is do we actually need to segregate things by orgs ? Arent's teams sufficient ? Why can't the kernels be under the Jupyter's Kernel Team for example ?

Note that the above would require a change in governance, and clear standards of onboarding and offboarding repos onto those orgs, as well as org ownership.

As long as a repo is under a given team it should not be a problem, for example, the rust-lang org has ~180 repo, and us projects (which are public and org-wide).

[blink1073]

I personally don't think teams are sufficient, for two reasons:

• Discoverability: Being able to find repositories, especially pinned ones
• Separation of concerns: trying to fit too many activities in one org that have different needs

[Carreau]

Try to restart this limited proposal, for a step by step what about just doing step 1 for now:

Jupyter-attic: Github Now has the "archiving" feature. I suggest to move all repos from jupyter-attic back to Jupyter and use the archiving feature.

No more, no less, that is already decreasing from 9 to 8, which a bit more than a 10% reduction in number of orgs.

[Carreau]

(Side addition, technically IPython also rely on https://github.com/pickleshare which we are the only maintainers as well, It's another discussion but I think we should fold that repo back into this at some point).

[blink1073]

I agree we can get rid of jupyter-attic. For pickleshare, why not bring it up to the Jupyter Foundations and Standards council to move the repo to ipython?

[Carreau]

For pickleshare, why not bring it up to the Jupyter Foundations and Standards council to move the repo to ipython?

That is a good idea, I'll reach out to the rest of the Jupyter Foundation and Standards.

For Jupyter-attic, I'd love a few more +1 before moving it, unless you agree that this is a low traffic enough repository that we don't need to have EC approval.

[blink1073]

jupyter-attic isn't called out in our governance docs, I view this as housekeeping.

[Carreau]

Ok. Then when I have some time I'll move all the repos (which are already archived) to jupyter. Unless there is someone that opposes to it in the meantime.

There are "only" 36 repos, so I'm likely to do that by hand instead of a script.

[Carreau]

I did not even realize that ec-team-compas is on it's own organisation called jupyter-governance.

Does this really have to been it's own org ?

[Carreau]

jupyter-attic isn't called out in our governance docs, I view this as housekeeping.

All repos migrated back to Jupyter, and marked as Archived, the Jupyter-attic org itself has been archived.

[Carreau]

25 is one more symptom.

I also discovered https://github.com/jupyter-native – which is empty.

[krassowski]

Oh, repos from attic are back in jupyter/ org? I was a huge fan of that solution and was trying to advocate it more. There are many novice e.g. googling "jupyterlab-debugger" which brings up https://github.com/jupyterlab/debugger and then they break their environment by following the severely outdated instructions in there (of course this is despite a clear banner saying it is archived); moving things like that to attic would have added another layer of "do not use me" disclaimer. Of course the problem that I am highlighting can (and should) be solved by other means (either us or GitHub improving messaging in the archived repositories, for example by modifiyng their READMEs)

Anyways, attic is dead, long live a single org to rule them all!

[jtpio]

I also discovered https://github.com/jupyter-native – which is empty.

This one can likely be deleted. If I remember correctly, it was an alternative to https://github.com/jupyter-xeus at the time the xeus proposal was created.

cc @SylvainCorlay @JohanMabille

[Carreau]

This one can likely be deleted. If I remember correctly, it was an alternative to @jupyter-xeus at the time the xeus proposal was created/

I'm happy if you want to keep it, maybe just remove the Jupyter Logo

[Carreau]

Oh, repos from attic are back in jupyter/ org? I was a huge fan of that solution and was trying to advocate it more. There are many novice e.g. googling "jupyterlab-debugger" which brings up jupyterlab/debugger and then they break their environment by following the severely outdated instructions in there (of course this is despite a clear banner saying it is archived); moving things like that to attic would have added another layer of "do not use me" disclaimer. Of course the problem that I am highlighting can (and should) be solved by other means (either us or GitHub improving messaging in the archived repositories, for example by modifiyng their READMEs)

Oh, we can still rename the repository and push a single commit that delete all files but readme on more repos, any particular repo we need to do that ?

[krassowski]

After some confusion, I interpret that @Carreau comment on the other issue (https://github.com/jupyter-governance/ec-team-compass/issues/25#issuecomment-1894186079) was encouraging me to move my comment from the other issue here, so here it is:

Just to spell it out, it looks like we are stuck in a bad place here (either inconveniencing maintainers or security team) because we are using a free produce whereas the platform also offers a paid version which does not have the limitation that the security team is facing:

One of the main differences between GitHub Enterprise Cloud and other plans for GitHub.com is access to an enterprise account. Enterprise accounts provide administrators with a single point of visibility and management across multiple organizations. For more information, see "About enterprise accounts."

Link: https://docs.github.com/en/enterprise-cloud@latest/admin/overview/about-github-enterprise-cloud

[krassowski]

So apparently Jupyter is now using Enterprise as per comment from @fperez https://github.com/jupyter/enhancement-proposals/issues/122#issuecomment-2099501888. This should resolve the issues which made the security team pursue reduction in the number of orgs :tada:

[jasongrout]

See https://github.com/jupyter/governance/issues/219 for more info about the enterprise org.