Ctrl+K

2024 Collaboration Cafe Notes Archive#

2024-03-19#

Check-in#

  • Min / @minrk / Simula

  • Sarah Gibson / @sgibson91 / 2i2c

  • Mike Krassowski / @krassowski / Quansight

  • Erik / @consideratio / 2i2c

Celebrations and Shout-Outs#

  • Thanks to Erik, assisted by Yuvi, for working on jupyter-server-proxy security patch

Agenda#

2024-02-20#

Check-in :raising_hand:#

  • Min / @minrk / Simula

  • Sarah / @sgibson91 / 2i2c

  • Samuel / @sgaist / Idiap Research Institute

  • Kirstie / @KirstieJane / The Alan Turing Institute

  • Simon / @manics / University of Dundee

  • Steve / @stevejpurves / Curvenote | MystMarkdown

Introduce yourself! :wave:#

If you are new to the meeting, add your name below and you can introduce yourself at the start of the meeting.

  • Kirstie Whitaker - Programme Director for Tools, Practices and Systems at The Alan Turing Institute. Founder of The Turing Way. Very interested in open source governance (EDI, accountability, transparency, project management etc)

Agenda :clock2:#

  • Kirstie (15mins): CZI Essential Open Source Software for Science (EOSS) Diversity, Equity and Inclusion (DEI) funding revamp proposal

    • https://docs.google.com/document/d/1pSU9kG_XDOSTF4JcbIt18hep1rCHIjuUYuYi5mg0q-0/edit?usp=sharing

    • Sarah found Outreachy is not well suited to the capacity of JupyterHub’s community

    • There isn’t a dedicated leadership meeting for the council

    • Proposal:

      • develop community engagement strategy and identify contributor blockers by speaking with the leadership council

      • not building a specific community development guide and create clearer x-refs between Jhub team compass and The Turing Way building on Jhub community’s needs

      • building trainers for community members to mentor new contributors

      • embedding inclusive practices into Jhub community

    • Questions?:

      • How to address the issue of feeling empowered to do stuff (Kirstie specifically?) Where to do the work (project is spread out), lack of clarity and explicitness makes things difficult, make sure we’re raising issues on what is unclear, raising things and not getting a response, escalation process to ensure Kirstie has support

        • KW will come along to collab cafe regularly to report back and escalate

        • It’s a feature to identify the barriers

        • KW wants to know how accurate is the membership of the jhub council? Can anyone identify any risks of talking to the council about what it means to lead the project? E.g. “Don’t do X”

          • Variety of interaction in the council, and there isn’t a clear set of expectations in what the council is doing

          • different types of leadership, technical decisions, community management, organisational leadership, paid development time

  • Steve (15mins): Contributing a new content/repo provider (MECA) to BinderHub/mybinder.org - how to?

    • Notebooks Now! project run by AGU, funded project to pilot using Notebooks to build interactive, computational article, and formally publish them

    • How to integrate with XML format (specifically JATS used by journals, also comes with a zip file MECA) so that Notebook-based publications can be accepted

    • MECA is an existing NISO standard (https://www.niso.org/standards-committees/meca) , modify JATS to also understand Notebooks, and bundle MECA with the binder requirements for launching. Completely disassociate from a GitHub repo.

    • https://agu.curve.space - demo website showing what the journal might look like

    • New repo-provider “MECA for binder”, how to get code into repo2docker? how to deploy it onto mybinder.org?

      • PRs:

        • #1335 on repo2docker repo

        • #1824 on binderhub repo

      • What’s the best way to take the conversation forward? How is the provider working and any improvement, technical review?

        • From Jhub side, barrier is review time/capacity, not necessarily that it shouldn’t be upstream

  • Kirstie (15mins): “I think this is the first barrier for you Kirstie 😉 A lot of folk turn up to this meeting with a “I have a PR, how do I push it forward?” style question”

    • We don’t have much of a review process at the moment and it is hard to allocate time and expertise to the review.

      • Do we make the decision in the meeting? How many people need to say “yes” for it to be a real “yes”!

      • Process isn’t written down.

    • The project is very technical and there are a lot of information siloes.

      • Some folks don’t feel confident enough to review (and that might be truely that they don’t have the expertise! Even if they’re leaders in the community.)

    • Identifying reviewers in advance can be hard.

    • Some other projects allocate a reviewer (often by a bot) and then they know that it is their responsibility to take the review forwards.

      • They become the point person so even if they don’t know the right details they can go and get the person who has the expertise.

    • Additional challenge around repo2docker as a specification - might have additional maintenance burden if edits are incorporated there.

    • Bias towards the more recent tasks and the easier or noiser tasks for reviewers.

      • Potentially needs a specific meeting (or async equivalent) to set the priorities

    • Hard to figure out how to reach consensus

    • “Yuvi and Sarah spoke to a governance expert on some of these things, I think section C here is particularly relevant”: https://docs.google.com/document/d/1WJMRR7ggIivmccrAjIgFWwLt9NYpzrn87ku-4GAFbnw/edit?usp=sharing

      • No actions taken yet.

    • Could try a bug triage activity - maybe part of the collaboration cafe on a regular basis.

2024-01-16#

Check-in#

  • Min / @minrk / Simula

  • Samuel / @sgaist / Idiap Research Institute

  • Simon / @manics / University of Dundee

  • Raniere / @rgaiacs / GESIS

  • Erik / @consideRatio / 2i2c

Agenda#

  • Min (15m): user-initiated sharing PR is complete and ready for review

    • key points for review:

      • architecture overview

      • permissions

      • defaults

      • pydantic v2 dependency

    • questions:

      • samuel: is a share-code single use or usable multiple times to grant users permissions?

        • min: its re-usable, and state is kept on how many times its used.

        • samuel: it would be a relevant feature to let a share code be usable once and only once

        • min: current inclination is to not provide once-use codes yet, but its not that hard to support

      • erik: when this is released, what a implication?

        • admins: enabling sharing

        • users: tricky but possible to generate share links

        • min: reference + tutorial + example is provided

      • erik: review scrutiny

        • review in scopes.py file is relevant to ensure stability, there is some refactoring related to “has scopes” which is used in “am i allowed” handlers.

        • there is now public api where it was previously private

        • min: besides this, there is review of relevance about granularity of scope and missing features

  • Min (15m): JupyterHub 5 planning

  • Min (10m): Security discussion

  • Samuel (10m): repo2podman ignore file management

    • PRs awaiting reviews

      • ignore file support

      • extra ignore file support

      • Points that needed some clarifications:

        • The ignore files are to be used at the Docker level and not repo2docker itself

        • The goal is to make repo2docker work in a similar fashion to podman and docker where files listed there will not be sent to the context and thus not part of the image

      • Possible issues:

        • May current repository break if these files are now being actively used ? It’s likely going to be a rare case.

        • The documentation should be improved to make clear that the ignore file do not apply to repo2docker itself.

  • Simon (3m) BinderHub versioning

  • Erik (3m) Z2JH breaking change merged requiring k8s 1.24+, and in end of january also k8s 1.25+ - I’m thinking we wait for jupyterhub 5 and focus on getting it out.

On this page
Edit on GitHub
Show Source