2021 Meetings


Meeting roles

  • Meeting facilitator: @choldgraf

  • Meeting recorder: @choldgraf

  • Meeting timekeepr: @choldgraf


Follow-up items

  • [x] Implement new team practice around asking for help

    • [x] Rename “Needs Review” to “Needs Input”

    • [x] Add labels for needs:decision, needs:review and assume all other issues in that column are generic “I need help” issues

  • [x] Plan to move meetings to Tue/Wed/Thu to avoid time when people may be off on Mon/Fri:

Team coordination check-in

  • How is the current sprint planning process working for folks?

    • Deadlines / specific plans have helped reduce “all the cool stuff we could do” into specific things, which have helped

  • How can we encourage discussion of non-sprint items, and review of one another’s work?

    • Could define “streams” of work - implementation and discussion

    • What about a label?

      • Might not be visible enough

    • Discussion column?

  • Two kinds of discussions

    • Major big-level discussions that will take a lot of work, that might be split into many sub issues etc

    • Stuff that just needs discussion to scope out a specific piece of work

  • Idea for feedback: two roles - Backlog Steward and Sprint Steward

    • Same person using both hats?

  • Can we use examples

    • Pangeo Hub issues

      • A lot of work was generated when we started making progress on this, and didn’t know about it ahead of time

  • How to ensure that team members are there to help one another

    • Create a culture of “it’s OK not to know”

    • Team Syncs have been helpful, specifically for “what am I up to, and where can I use help?”

  • When we realize that work is more complex than we realized

    • We need to avoid falling into a work hole

    • Need to encourage focused discussion in these situations, with specific questions to answer

    • If we have an issue like this, we could create a dedicated issue for it and put it on the board

    • “Needs decision” label could be more useful than “needs discussion”

  • Concern that a weekly update is not often enough if people need help

    • What about a daily standup-style system? e.g., with Geekbot on Slack

    • Concern that this would become a very noisy channel

    • Could we just accomplish this with more encouragement to provide updates in the #team-updates channel

    • If we grow and bring on people that are less comfortable in working with us already, it may be less inclusive to them to just generically ask them to ask for help.

  • Using a column for “needs help”

    • Currently we have a “needs review” column - but needs review is just a subset of “needs help from others”

    • Could we re-name the “Review” column with “Needs Input”

    • Include labels to separate issues in this column

      • needs:decision

      • needs:review

      • For issues in this column instead of

  • Building a team practice of “collectively owning” sprint items

Skipped items

  • Capacity Building

    • We might have some resources available to hire or contract - where do we need capacity now?

    • For building capacity internally - what’s the best way to learn new skills or train team members?

    • Idea for feedback: develop 2i2c teaching/learning materials specific to JupyterHub DevOps.


Meeting roles

  • Meeting facilitator: @choldgraf

  • Meeting recorder: @damianavila

  • Meeting timekeepr: @choldgraf

Welcome to the Team Meeting


If you are joining the team video meeting, sign in below so we know who was here. Roll call:

  • name / GitHub handle

  • Sarah / @sgibson91

  • Damian / @damianavila

  • Yuvi / @yuvipanda

  • Erik / @consideratio

  • Chris / @choldgraf

Follow up items

  • [x] Chris sends the Binder cross stitch to his mom!

  • [x] Revisit times for the deliverable and monthly meetings (there are conflicts with other meetings)

  • [x] Define a strategy and high-level description of “the 2i2c pilot”

  • [ ] Updates to our board process

    • [x] More tightly couple the “deliverables meeting” with the “activity board”

      • The meeting’s goal is to put things on the activity board.

      • Each item should have a person assigned to it

      • Should use best judgment about workload balance and making sure we’re not overextended

      • We should make a new board per each sprint, and treat it as immutable as possible

    • [x] De-commission the “Deliverables Backlog” and “Organizational Backlog” from “official board status”

    • [x] Simplify the “Activity Board” so that it has fewer columns and complexity.

      • Remove the “needs review” column, and instead write up a process to use GitHub review requests

    • [x] Temporarily make the deliverables meeting a weekly meeting, set up a plan to try this for ~3 months with the goal of moving to bi-weekly at teh end.

  • [x] Updates to Support Steward signal boosting

    • Define a process for the Support Steward to use the hub-support channel to signal boost issues for others.

  • [x] Yuvi will write up a proposal for PR merge and review process:

Reports, updates, and celebrations

This is a place to make announcements (without a need for discussion), short updates about what you’ve been up to, and shout-outs to contributors! We’ll read through these at the beginning of the meeting.

  • ICSI invoicing plan:

  • We’re going to get the CZI EOSS grant for Community Strategic Lead!

    • This will open some addditional time/resources for pangeo stuff

  • Sarah is making progress on the pangeo deployment

    • Some new terraform stuff

    • This is some context on the headaches side

      • Long process/negotation, when you say no, draw a line

      • Private node is probably needed, but how we are going to manage the logins

      • What we are piloting? We need a expectation setting tool

Agenda items

Team Boards discussion / process

Start: 5:56pm (30-45m)

  • Relevant issue

  • What kinds of issues go on deliverables boards vs. on activity boards?

    • Current split is “deliverables vs. actions”. Should it be something else?

  • What does it mean for an issue to be in a deliverables board?

    • Is it a commitment to work on the issue? An indication of prioritization?

    • Should all issues be on a board one day? Or should a criteria be met before they go to a board?

    • If the former, how do we avoid deliverables boards becoming gigantic lists of issues?

    • Does it make sense to have an “organizational” and an “development” deliverables boards? Is there a better split?

  • What does it mean for an issue to be on the activity board?

    • What is the process that puts issues on the activity board?

    • See below for agile proposal process.

    • How do we use this workflow to work on projects with different focus areas? E.g. Pilot hub infra vs. Executable Books vs. Upstream improvements

  • How do we encode new work items that pop up (e.g. support requests that we must prioritize)?

  • Proposal: Agile process around the boards

    • Roughly follow an “agile” approach to these boards, and use our deliverables sync meeting to plan out the next two weeks of things to follow?

    • Should we roughly tie the language of agile to our workflows? E.g. “things on the deliverables boards are ‘epics’, things on the activity board are ‘stories’”?

  • How do we encode questions, discussions, and decisions with team members?

  • Where to store “ongoing information that requires attention over time”?

    • Things like “pinned issues”, but for a board?

    • Does it make sense for us to use an “info” column for ongoing information? (sort of like an “announcement board”)

      • If so, what rules should we put in place for this so it doesn’t become super large?

    • If not, where else should they go? Regular issues that fit into our deliverables/activity board split like anything else?

  • How do we signal ‘person X needs to pay attention to this’?

    • Use GitHub reviewer requests?

Discussion Notes

  • Team members unsure how to use the boards, and would like some simplification.

  • People are often working entirely on their own projects - unclear where the board is helpful if you’re always in your own space.

  • Folks are used to using notifications to decide what to work on, board is a secondary place.

  • Boards are useful because they are intentional, not “push-driven”

  • Maybe the boards are not “action-oriented” enough

  • Need a way to keep track of long-term items, but the activity board isn’t best place for this

  • Need a way to estimate our capacity and short-term commitments

  • Good to use GitHub-native features as much as we can E.g. “request for reviews”, “issue assignments”

  • Decide to use the Activity board as a part of our team deliverables review

  • Move deliverables review to weekly for a few months to test it out.

Skipped / backlog items

After our meeting, we should move items here that we didn’t discuss or decided to delay for future meetings. We don’t have to re-visit them in future meetings, but this helps us keep track of potential future items.

FreshDesk communication pathways (15-30m)

  • Relevant issue

  • Is the Support Steward the only one expected to check and respond to FreshDesk questions?

    • Is it OK that this is creating a bottleneck? (e.g., if the Support Steward is asleep is there no support responses expected at all?)

    • Example of an issue that benefited from multiple perspectives:

  • When we create a ticket after a support request, do we still expect Community Representatives to communicate via FreshDesk, or is it OK for them to start responding in the GitHub issue?

    • Is it OK that this is creating a bottleneck? (if multiple people from a community cannot see the same ticket?)

Team process for merging and review (15-30m)

  • Relevant issue

  • When can a team member self-merge a PR?

    • e.g., after one approval? in some cases without any other approval?)

  • When should a team member merge another team member’s PR?

  • What signals can we create to make this easier for team members to track?

    • Columns in a project, issue labels, etc?



  • Erik Sundell / 2i2c / @consideratio

  • Damián Avila / 2i2c / @damianavila

  • Sarah Gibson / 2i2c / @sgibson91

  • Chris Holdgraf / 2i2c / @choldgraf

  • Yuvi Panda / 2i2c / @yuvipanda

  • Georgiana Dolocan / 2i2c / @GeorgianaElena

Reports, updates, and celebrations

Agenda items

  • Welcome to Sarah and Damian (5m)

    • Quick intros and hellos

    • and welcome to everyone, since this is the first meeting!

    • Damian and Sarah introduce themselves

  • Support Steward proposal (10-20m) (07:35)

    • any feedback / suggested changes / etc? Shall we plan to begin the support steward role soon?



    • Feedback?

      • ES: two weeks sounds good to him

      • DA: we should make sure to keep the “support ticket” board separate from the deliverables board

        • Open issues across boards, cross-link them if need be

        • Goal of the support tickets would be to “create items in the technical board”

      • CH: How could we make sure that the support steward has the support of others on the team, not just doing it all themselves?

        • ES: We could define a process that the person could follow to make sure they don’t get “tunnel vision”.

          • Their job is to make sure that concrete work items are availble to get the work done, but not necessarily do the work themselves.

        • DA: One way you could do this is to give the support steward the ability to assign others to help them with items.

        • TODO: we’ll try the approach in the proposal and see how it goes, make changes as needed

        • TODO: define an official process that the /support repository is where the support tickets come into

  • How to incorporate issue / deliverables review into this meeting? (10-20m) (07:54)

    • We’ve discussed using this meeting to review things that we’re working on, prioritize, etc

    • Is there a way we can incorporate this into the team meeting?

    • Sprint meetings, working through the project board, limit to 30mins

    • Will conflating a team discussion with sprint meetings eat into each other’s time? But also, we’re in different time zones and arranging another meeting is overhead

    • DA agrees with SG that a dedicated sprint meeting separate to team discussion meeting might be best

    • TODO: set up a separate meeting time slot. maybe every 2 weeks and do the support steward swap as well.

    • CH: is it OK if people skip every other meeting because of timezones?

      • YP: intuition is that it’s better to have a single meeting group rather than two groups of meetings

      • CH: is this time sustainable? (Yuvi: Yes, if I don’t return to CA :P)

  • Discuss possible interaction with JupyterHub team meeting & Pangeo meetings (08:10)

    • We want to avoid having “community drift” between the Pangeo / JupyterHub meetings

    • We should make sure that we are systematically publicizing the work we’re doing across these meetings

    • We need intentional processes around information sharing between different groups

    • TODO: Bake this information into an “open source strategy” for 2i2c.

      • Information share between upstream projects that are related

      • Make sure we don’t speak “on behalf” of upstream projects - we can have wishes but ultimately need to work with the community

      • Keep track of our “upstream” work items (e.g., in /external)

  • Discuss a new opportunity from Chelle @ NASA


    • YP: thinks it is super awesome, but also a ton of work

      • Tons of bureaucracy and red tape

      • TODO: figure out how many of the challenges here are technical vs. administrative

      • TODO: Consider having a dedicated person to do the wrangling / coordination / etc

    • DA: Good opportunity to be at the center of something awesome, but also a ton of effort

    • ES: Excited about a broader scope of open source development we could in a somewhat sustainable way from 2i2c via this, but indeed it would be complicated and would needs a dedicated person working on it.

  • Team Photo? :joy:

    • TODO: chris should put this photo somewhere

    • Oh no, Chris couldn’t find the photo anywhere on his computer! Somehow it was not taken :-(


  • Discuss a new opportunity with the GESIS team (skipped)

  • Real Time Collaboration (Erik, skipped)

    • Start jupyterlab with --collaborative, or more conveniently with --LabApp.Collaborative=True

    • Let users create a token at /hub/token

    • Let users share links with the query parameter &token=

    • Warn about that this gives whoever has the link access to act as that user, just as if there were logged in. It is a very dangerous link to share or happen to make public by mistake.

  • Discuss BinderHub development (skipped)


Chris Holdgraf

Thanks I’d like to give 🙌

  • Thanks to Yuvi and Georgiana for giving feedback on the team process issue around goals!

Updates from last two weeks ✔

What I’m up to next ⬜

  • Beyond finalizing those two issues, I’m going to work with Yuvi a bit to improve our documentation for the 2i2c Hubs!

Erik Sundell

Thanks I’d like to give 🙌

  • Thanks Yuvi for your encouraging spirit (love bombing twitter)!

  • Thanks Chris for your attentive leadership (clear and quick responses)!

Updates from last two weeks ✔

  • I have taken some time off.

  • I have done a bit more review work than usual and less development efforts of my own.

    • Z2JH feature prePuller.hook.pullOnlyOnChanges is now available though btw

  • I have helped Ariel with an AWS deployment

What I’m up to next ⬜


Chris Holdgraf

Thanks I’d like to give 🙌

  • Cathryn and Jim have both been very helpful in helping me think through some high-level strategic questions about 2i2c!

  • Ryan Abernathy and Georgiana both helped interview our job candidates, and their feedback was invaluable!

Updates from last two weeks ✔

  • The last two weeks have all been about doing diligence on our applicants, and working with ICSI to understand how we can open up our first sales with them.

What I’m up to next ⬜

  • The work with ICSI is ongoing, but I think that we are getting closer. I’ve got a draft of a contract that they’re sending to a lawyer soon, and then we should be able to start accepting money for running hubs.

  • In addition, I hope to hear back from the two job candidates in the next few weeks about their decision!

Erik Sundell

Thanks I’d like to give 🙌

  • I’m thankful for all 2i2c members for their efforts into building this org! :heart:

  • I’m thankful for Yuvi’s positive and uplifting comments and help reviewing various PRs! :heart:

Updates from last two weeks ✔

  • I’ve done a little bit of this and a little bit of that across the JupyterHub org (Example general maintenance PR), but I’m currently most excited about this pr. It is finally getting the z2jh configuration reference updated to fully cover the available config options and at the same time including a jsonschema file that helm can use to catch various config errors for users of the chart and provide sensible messages while doing so.

What I’m up to next ⬜

  • Pushing onwards to z2jh 1.0.0, after the schema validation logic I want to acquire an “official status” on where it is listed and make do a pass at the z2jh documentation so it is updated with lessons learned across time.

Georgiana Dolocan

Thanks I’d like to give 🙌

  • To Chris for giving me the opportunity to participate in the interview process, it was a great learning oportunity

  • To Yuvi for explaining every technical concept so well.

  • To Erik for all the work in z2jh and making jupyter-server-proxy fully compatible with JupyterLab3

Updates from last two weeks ✔

  • These past weeks, I’ve worked on setting a new hub for the Mills College, upgrading the hub version in pilot-hubs as part of the process. I also tried to make the hub health checks more robust and investigated the use JupyterLab3 with the pilot-hubs.

What I’m up to next ⬜

  • TLJH needs some <3, so I’ll try to get it a bit more up to date

  • Investigate if our current Auth0 setup can support multiple hub authentication methods


Erik Sundell

Thanks I’d like to give 🙌

  • Min put in a lot of effort to help me review PRs and it made me very happy!

  • Yuvi pinged me about technical inspiration (database class where each user has a dedicated database available). It is inspiring, I’m excited about the possibilities that open up in educational settings by removing various technical barriers to get started without getting stuck in hardware setup / software installation / licenses etc.

Updates from last two weeks ✔

  • I’ve worked on z2jh PRs towards 1.0.0, where the following updates can be relevant to know about:

    • hub.extraFiles / singleuser.extraFiles This feature can help 2i2c deployments by offloading you off the logic to do define volumes/volumeMounts and helping YAML/JSON/TOML file to be mounted be configured from multiple helm configuration files (config.yaml / secret.yaml). It is also possible to have standalone files but then you must use –set-file during helm upgrade which is a bit messier.

    • seed secrets + followup fix This feature makes us no longer need to set or pass proxy.secretToken, hub.cookieSecret, or auth.state.cryptoKey - they will be automatically generated if not explicitly set.

What I’m up to next ⬜

  • Pushing onwards towards z2jh 1.0.0

  • Write a paper with Ariel Rokem for PEARC about neurohackademy

Links to items for discussion 💬

  • I’d love help to get the extraFiles PR towards merge.

    • Thank you Chris and Yuvi for your previous review!! Your previous review points have been addressed now!

  • I’d also appreciate a of the seed secrets followup fix.

  • I’m generally curious about developing a solution to providing a authentication proxy for JupyterHub’s services, communicating with JupyterHub as an identity provider and relying on JupyterHub group membership something to decide if the user should be granted network access to the service - such as /services/docs for example. I’m not sure yet how to go about it, but I think it would be one of those somewhat general purpose tools and those motivate me a lot to work on!


Thanks I’d like to give 🙌

  • To Georgiana for:

    • Taking full responsibility for working with Aaron Culich on the Mills hub

    • Writing full fledged health checks for hubs, so we have more confidence that they actually work

    • Fixing bugs with the UToronto hub as they get reported

  • To chris, georgiana and ryan for helping run intterviews

  • To chris for organizing everything so we don’t all drown

Chris Holdgraf

Thanks I’d like to give 🙌

  • Thanks to Yuvi for giving Georgiana so much guidance on the Toronto hub!

Updates from last two weeks ✔

  • Dealing with 100% parenting + 100% working (fun!)

  • Working on moving forward some more contracts for 2i2c (see

  • Refactoring some of our team process / communication / workflow

  • Setting up hiring practices that we can use for the OSIE hire + future ones!

What I’m up to next ⬜

  • Figuring out our budget situation for the next 2 years

  • Finding a way to spend my Jupyter Book grant!

  • Thinking more about prices + features + products strategy

  • Hiring somebody!



Thanks I’d like to give 🙌

  • Thank you everyone for connecting and establishing collaborations between 2i2c and so many amazing groups of people! I’m excited about 2i2c helping them!

  • Thanks Yuvi for addressing the challenge of standardizing Grafana Dashboards for z2jh deployments!

  • I’m very thankful for @manics work, most recently for creating and working with me on the jupyterhub/action-k3s-helm GitHub action we now reuse for four or more JupyterHub projects.

Updates from last two weeks ✔

  • I’ve worked generally motivated by making JupyterHub repositories maintenance more sustainable by reducing complexity, improving CI, improving docs, and pushing for a 1.0.0 release of z2jh.

What I’m up to next ⬜

  • Z2JH 0.11.0 release.

  • Z2JH 1.0.0 features relying on Helm 3 to reduce complexity such as needing to manage proxy.secretToken etc.

Links to items for discussion 💬

  • Merging this Z2JH PR is what remains for the 0.11.0 release. I have looked for help to review it but the JupyterHub team membars are generally low on capacity. I’m not happy about either of the options I see: to wait, to self merge, or to repeat requests for help.

    Any ideas on how to manage this general situation and this specific PR is greatly appreciated. In general I currently wish for the JupyterHub team to compromise a bit on review stringency during times when reviewer’s availability are low. It would be nice to have some guidelines.

  • Meta discussion: Did I use this team-sync somewhat as intended? Any suggestions for changes in any form?


Thanks I’d like to give 🙌

  • Many thanks to Yuvi for being a great mentor and for all the time and effort put in getting me familiar with the 2i2c projects and technology.

  • Thanks for Chris’ great work in growing 2i2c and for the great oboarding process created.

Updates from last two weeks ✔

  • These past weeks, I spent most of the time working on getting familiar with the 2i2c pilot-hubs, fixing a couple of issues and reviewing a few PRs as part of the process.

What I’m up to next ⬜

  • Supporting Yuvi in getting the UToronto hub ready for the winter semester.

  • Developing tests to check and ensure the pilot-hubs’ health.


Thanks I’d like to give 🙌

  • Thanks to Erik and Geo for joining the first team (a)sync :-)

Updates from last two weeks ✔

  • We’ve just submitted two NSF sub-awards, one for a satellite mission at Texas Tech (well, this one was a pre-award), and another for a collaboration with UW and others around collaborative cloud science!

  • This has also involved a lot of discussion with ICSI about how to manage these collaborations etc.

  • I have eaten a lot of 🧀 and drank a lot of 🍷 with my French family.

What I’m up to next ⬜

  • Wrapping up the next few collaboration proposals

  • Starting the hiring process for the open OSIE position

  • Updating our team compass docs with things we’ve learned after the last few proposals we’ve written

  • More about hub pricing and “products” that we offer

Links to items for discussion 💬

  • Just a general one - check out the team compass! and please don’t hesitate to contribute anything to this that you think would be useful.