Merge pull request #689 from sgibson91/oct-collab-cafe-notes

Add October Collab Cafe notes

docs/meetings/collab-cafe/2023.md

@@ -1,20 +1,70 @@
 # 2023 Collaboration Cafe Notes Archive
 
+## 2023-10-17
+
+### User-initiated sharing
+
+- **Description:** Implementing user-intiated sharing,
+  there are some things to work out in the design.
+  Min has done some partial implementations,
+  but switched to documenting how it _should_ work before finishing any implementation.
+  [Draft PR here](https://github.com/jupyterhub/jupyterhub/pull/4594).
+
+#### Notes
+
+- don't get too complex for first draft
+- invite coes may solve discoverability
+- limit user:user grant to read access for read:user:name (separate share-with scope later, if needed)
+- make it opt-in
+
+### Why should HPC folk care about Binder/be interested in it?
+
+- **Description:** Sarah has been asked to present on Binder to a HPC workshop. I can give the "reproducibility with Binder" bit, but I'm looking for angles to make this interesting for the HPC audience. I think there's a "Cloud vs HPC" culture and a "sysadmin won't let me run docker on the cluster" pushback to navigate. So I'm thinking about how to frame this as "so this _exact_ tech stack doesn't fit your needs, but here's some lessons learned". Also, I think the workshop is for a tool that helps with reproducible workflows on HPC, so I don't think they'll actually use Binder/repo2docker at all (though I don't know much about the tool) <https://hpc.guix.info/events/2023/workshop/> Drafting abstract and talk outline: <https://docs.google.com/document/d/10LnhlWXi_ZSNHUphT5-CiSlSb7tssT5_uMh9bRX4Mo0/edit?usp=sharing>
+
+#### Notes
+
+- Questions: What's the pitch? You should use this tool vs what to learn from this peer project?
+- <https://github.com/ncar-xdev/repo2apptainer>
+  - Is this tech (singularity/apptainer) still being pitched to HPC centres?
+- Use Guix inside repo2docker? <https://github.com/jupyterhub/repo2docker/pull/1048>
+- r2d automates good practices where they exist, getting Guix practices into r2d is within scope! <https://github.com/jupyterhub/repo2docker/pull/1048>
+- Meet them where they are: use podman/singularity instead, are they happy to run containers at all? Do they see a need for containers?
+- What dependencies do you need to install, and what command to execute to run them? <https://repo2docker.readthedocs.io/en/latest/specification.html>
+  - How do they envision reproducibility working outside of their ecosystem
+- \[Simon\] AFAICT Apptainer can't bulid from a Dockerfile, so either you'd need to convert a Docker image, or convert the Dockerfile to an apptainer definition file
+  <https://apptainer.org/docs/user/main/build_a_container.html#building-containers-from-apptainer-definition-files>
+- Host outside HPC the ability to build images, only permit launching images inside HPC, e.g., GESIS work on preventing Binder from launching images
+
+### JupyterHub-Contrib proposal draft
+
+- **Description:** Outcome of meeting with Sumana a few weeks ago, <https://hackmd.io/TrI2lZSJS5e3cS7y9wcMfw?both> is a very draft proposal about a `jupyterhub-contrib` organization, and how that may work.
+
+#### Notes
+
+- S: How do we possibly use template repo to share cultural project expectations?
+  - Min: This is in the team-compass stuff, need more things written there than we have now
+
+Possibly a template for the `jupyterhub` org but a `cookie-cutter` for the contrib org?
+
+### `@jupyterhub/binderhub-client` npm package
+
+- **Description:** Yuvi is trying to clean up the frontend JS of binderhub, and part of that is maintaining a JS package that can be used by various clients that need to talk to the binderhub API. It's at <https://github.com/jupyterhub/binderhub/tree/main/js/packages/binderhub-client> and has seen a lot of work recently. No specific ask, just a report that this is happening
+
 ## 2023-09-19
 
 ### AWS/Curvenote MyBinder federation member
 
 - **Description:** New AWS/curvenote mybinder federation member: Steve Purves has donated AWS credits and is keen to become an official member. Feedback welcome on this PR
-    - <https://github.com/jupyterhub/mybinder.org-deploy/pull/2652>
-    - Related discussion/background: <https://github.com/jupyterhub/mybinder.org-deploy/issues/2556>
+  - <https://github.com/jupyterhub/mybinder.org-deploy/pull/2652>
+  - Related discussion/background: <https://github.com/jupyterhub/mybinder.org-deploy/issues/2556>
 
 #### Notes
 
 - Will it work against AWS ECR? Next PR
-    - Deployment of cloud infra is in one PR: <https://github.com/jupyterhub/mybinder.org-deploy/pull/2652>
-    - The BinderHub chart is deployed with extraConfig that defines a new DockerRegistry sub class that takes care of the complexity of working against a AWS ECR container registry (by interacting with a Golang based service Simon has developed).
-        - <https://github.com/manics/binderhub-container-registry-helper/tree/main#api-endpoints>
-    - Curvenote BinderHub chart deployment: <https://github.com/jupyterhub/mybinder.org-deploy/pull/2698>
+  - Deployment of cloud infra is in one PR: <https://github.com/jupyterhub/mybinder.org-deploy/pull/2652>
+  - The BinderHub chart is deployed with extraConfig that defines a new DockerRegistry sub class that takes care of the complexity of working against a AWS ECR container registry (by interacting with a Golang based service Simon has developed).
+    - <https://github.com/manics/binderhub-container-registry-helper/tree/main#api-endpoints>
+  - Curvenote BinderHub chart deployment: <https://github.com/jupyterhub/mybinder.org-deploy/pull/2698>
 
 ### Lowest level of maintenance for JupyterHub org project's
 
@@ -27,10 +77,10 @@
 - Sarah is in touch with an experienced leader, [Sumana](https://www.changeset.nyc/about-us/), might be available to for discussion on open source leadership. Sarah is meeting next week.
 - Clarify expectations of what level of support comes with being under "jupyterhub" name
 - There is a [proposal for `jupyterhub-contrib`](https://github.com/jupyterhub/team-compass/issues/519) which doesn't indicate support in the same way
-    - Could have a low bar top accepting repositories
+  - Could have a low bar top accepting repositories
 - Being included in a distribution (z2jh, tljh) also raises the bar for expectations
 - Clear expectations is a good thing, and can be contributing to ecosystem in general
-- A while ago we had a discussion about how git ownership/maintainership confers status, and we wanted to move away from that to include people who do community work and other tasks not directly related to code 
+- A while ago we had a discussion about how git ownership/maintainership confers status, and we wanted to move away from that to include people who do community work and other tasks not directly related to code
 
 ### Drafting a new Roadmap
 
@@ -64,13 +114,13 @@ Let's think about the release of the z2jh helm chart, and any packages that coul
 - Stating long-term things we aren't working on is still useful, and can motivate contributors or funding
 - Separate roadmaps for aspirational (funding), practical (what we have capacity to do short-term)
 - Roadmap - long term items:
-    - supporting multiple replicas of jupyterhub
-    - moving away from CHP
-    - repo2docker reproducibility
+  - supporting multiple replicas of jupyterhub
+  - moving away from CHP
+  - repo2docker reproducibility
 - Roadmap - short term item nominations:
-    - establish maintenance expectations on projects in jupyterhub gh org
-    - reporting/metrics (jupyterhub-grafana)
-    - e.g. "focus on releasing z2jh 4"
+  - establish maintenance expectations on projects in jupyterhub gh org
+  - reporting/metrics (jupyterhub-grafana)
+  - e.g. "focus on releasing z2jh 4"
 - Org-level, at least, maybe tying to releases is not a good fit. Instead more time-based "short-term/long-term"
 - Roadmaps don't let us tell volunteer contributors what to spend their time on (but they also kind of do!)