Ctrl+K

2021 Meeting Notes

Contents

2021 Meeting Notes#

2021-12-07#

  • Meeting facilitator: @choldgraf

  • Meeting timekeeper: @choldgraf

  • Meeting recorder: @sgibson91

Follow-up items#

All of the discussions here were already encoded as issues and google docs (linked in the sections below)

Project Planning proposal#

Proposed new Project Planning process for the team

  • Proposal document

  • How to balance development and operations as a team?

  • Problem to optimise: continuous backlog makes it difficult to build momentum towards a specific outcome, we pay more of a context-switching cost, and we do more context-sharing during the sprint meeting which isn’t ideal

  • Reorient coordination and planning process around more granular, longer-term project work

    • Exist between 2 and 6 weeks

    • Well shaped: what’s the problem statement?

    • But not a “task list”

    • Has an associated appetite: how much time we commit to trying to resolve a problem, how important is it to 2i2c? how interested are we in working on it? It is not an estimate of time to complete

  • Adopt a high-level project-planning approach

    • Assign a lead and support

    • They will see the project through to either completion or the clock runs out

  • 4 step process

    1. Shaping the project proposals: get a project well-specified enough in it’s outcome that we’ve identified rabbit holes, clear problem statement, and idea of what a solution looks like. These become the backlog.

    2. Planning: regular meeting (frequency TBD), people to pitch projects they think are important, team members and maybe external communities would “vote” in terms of impact. By end of meeting, people will be assigned, the “appetite” time begins.

    3. Building: Each project has it’s own mini-backlog of issues. People who work on the project are in charge of owning that mini-backlog. Handful of issues for a short time period.

      • Major constraint: the appetite is a hard limit on the project. By the time we reach this time, we should have shipped something. If the total scope isn’t completable within the timeframe: reduce the scope!

    4. Cool-down: break between projects. Wrap up previous project, work on miscellaneous tasks, take some time-off, check out the upcoming projects to vote on.

  • Concerns raised

    • Doesn’t feel like an iteration on old process, but a whole new one

    • How does support and operations fit around this new proposal?

      • Document is a goal, not a light switch. We can take baby steps.

TODO

  • Take some steps in this direction and see how it goes, then re-assess. (update issue with these new plans): 2i2c-org/team-compass#205

Team Context Sharing#

  • How can we encourage sharing information, context, and skills between team members?

    • Pair up in development?

    • Skill sharing sessions in team meetings?

    • Shared backlog meetings for people on the same project?

  • Could be solved by the pairing up suggested in above project planning agenda item

  • Pairing up sounds like a good first step and being more intentional about this

  • Asking for a review volunteer at the start of the work is good

  • Learning something new by reviewing a PR from someone more experienced who takes the time to explain what they’ve done to you is also a valid way of learning/context sharing

  • Define ahead of time who will work something on a team, focusses attention more rather than diving into unknown PRs (reviewing is still labour!)

TODO

Missed topics#

2021-11-09#

  • Meeting facilitator: @GeorgianaElena

  • Meeting timekeeper: @yuvipanda

  • Meeting recorder: @choldgraf

Follow-up items#

  • [x] Open an issue about updating the support steward process

Support steward feedback#

  • 2-person team instead of a single person?

    • Stagger by 1 week so that there is continuity in the team.

      • Maybe 2 weeks overlapping?

      • In that case any support steward would be serving 1 month on 50% load (first 2 weeks you are working with the previous steward and last 2 weeks you a working with the next one) and the transition still happen every 2 weeks on sync with the sprint cycle?

      • Overlapping would help reduce uncertainty about who is responsible for a ticket when people transition in/out of this role

      • Could also help reduce the response time on tickets

    • Feedback?

      • Reinforce the idea that the support steward is a router rather than a fixer

      • Write up specifically that they have the right to ask people for help, and folks can of course decline but they can ask and we should prioritize support tasks over dev tasks.

      • Another big role of the support steward is communicating. Need to reinforce that their job is to regularly speak with the support steward.

  • Target feedback-loop for support tickets

    • Target response time: <24 hours to respond (not to resolve) (and excluding weekends/holidays)

    • When you receive a ticket, communicate that you have received it and note the next steps you’ll follow to resolve it.

    • Give updates to the community as you work to resolve the issue

    • When it is resolved, tell the community what you’ve done to resolve the issue

    • In general, it is encouraged to prioritize support-related issues over development/backlog issues

  • How to handle communities with dedicated personnel

    • Questions still submitted via FreshDesk

    • Support team is still the main point of contact

    • The team can assign issues that are relevant to a specific community to another team member

    • SG: Is the fact that we have communities with dedicated personnel not a failure point that we should mitigate, rather than special case for?

      • YP: yessss. We can have dedicated personnell for specific events but not for entire communities

      • If only a subset of people are able to do work on the hub itself, then we need to distribute the knowledge/permissions to do this

      • It is OK for people to be tied to a community at the level of development, but this should not apply to support.

    • Conclusion

      • At the support level, there is no “community-specific person”

      • If only a subset of people know how to work on a hub, then this is an anti-pattern we need to get out of

      • But as support steward is router, people develop expertise in certain areas, and it’s ok to route requests to such a person. Also ok to route something to someone if they were just working on it / were very active in that space. Must be balanced against making sure we don’t pigeonhole people

One-to-one meeting for meeting facilitator transition#

  • Similar to the Support steward transition meeting

  • Exchange improvement ideas and feedback

  • Past meeting facilitator becomes the meeting recorder for the next cicle

  • Feedback?

    • Having a one-on-one would help people give feedback about what works, what doesn’t, etc

    • Giving advice and getting back feedback

  • Maybe this is more of a ‘personal skills’ and development issue, rather than something that needs to be attached to the role

  • Conclusion

    • Have a one-on-one meeting only if there is a need, don’t force it

Improvements to our backlog#

  • How can we bring the backlog into our sprint planning process?

  • Goal is to make sure that we are working on things that are high-impact and/or urgent

  • Would it help to add a step of reviewing the deliverables backlog to our sprint planning meeting?

  • Would a team role (e.g., “Support Steward”) help with this?

  • How can the engineering team help with prioritization and refinement?

  • Feedback?

    • How does this usually work in more traditional “agile” setups?

      • It is often a dedicated role (e.g. “Product Manager”)

    • Feels like 2i2c has enough complexity that it’d be hard to do this just in the first 15 minutes of sprint planning

    • Would it be a problem to just hire somebody to do this?

      • YP: would be great if we had the resources for this

      • This kind of role can also go poorly because open source communities may not be an easy fit for a traditional product manager

      • Though 2i2c is not an open source community, we could commit to team dynamics

    • How could we share the load more generally?

      • Specific verticals or parts of the infrastructure that each person cares about?

    • Could we grow somebody into this role internally?

    • When has it worked well in other communities?

      • When somebody has pre-existing respect within a community

  • Conclusion

    • We don’t know what is the right next step here, but agree that this is an important issue to resolve

    • We should

      • Collect information about our budget situation

      • Investigate whether team members are interested in this

      • Investigate whether we could bring in admin help to free up Chris’ time for this

2021-10-12#

  • Meeting facilitator: @choldgraf

Focus for these meetings#

  • Can we remove some of the high-level “check-in” stuff? General agreement is “yes”

  • What improvements can we make?

    • Structure the meetings from a high-level a bit more closely to make it easier to choose things to talk about

Follow-ups#

  • [x] Re-work the meeting structure to focus on the agenda and less about reporting / updating.

Cycling through team roles#

  • what’s a good process for doing this? (examples of roles below)

  • How can we facilitate the changing of roles?

    • If it’s just a generic sign-up sheet, people tend not to sign up

    • Instead, fix an order ahead of time

    • Term limits are roughly quarterly

  • Roles to use?

    • Support Steward

    • Meeting facilitator

      • The meetings we have: sprint meetings every 2 weeks, team meeting each. That’s 3 meetings a month.

  • Division of labor or everybody does every role?

    • We are a small team, so may not have the ability to divide labor

  • How can people be supported in this role?

    • Create a team culture of supporting the person who serves in this role

    • Encourage practices of skill-sharing and providing guidance to one another

    • The skills that come from this kind of role are general enough to be useful to all

    • In the future, we may want dedicated people in this role if we grow

Follow ups#

  • [x] Chris writes up descriptions of the support steward and meeting facilitator role

  • [x] Create a google sheet with an alphabetical list of team names, and use this to track dates for the roles

    • Meeting facilitator: switch each month

    • Support steward: switch each sprint

New GitHub Issues Beta#

  • Any objections to using them for ourselves?

    • Let’s do it!

Follow ups#

  • [x] Convert our project boards to new project boards and create new links.

Overview of Q3 update post#

  • General structure looks good

  • How do we highlight open source stuff?

    • Metrics of activity on github stuff

    • Collect public-facing stories that we can re-tell

Follow ups#

  • [ ] Chris writes a paragraph about our major open source contributions, and collects a few simple metrics to report.

2021-09-06#

Meeting roles#

  • Meeting facilitator: @choldgraf

  • Meeting recorder: @choldgraf

  • Meeting timekeepr: @choldgraf

Notes#

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: 2i2c-org/team-compass#237

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.

2021-07-02#

Meeting roles#

  • Meeting facilitator: @choldgraf

  • Meeting recorder: @damianavila

  • Meeting timekeepr: @choldgraf

Welcome to the Team Meeting#

Hello!

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” 2i2c-org/team-compass#192

  • [ ] Updates to our board process 2i2c-org/team-compass#188

    • [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 2i2c-org/team-compass#167

    • 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: 2i2c-org/team-compass#175

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: 2i2c-org/projects#5

  • 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 2i2c-org/team-compass#184

      • 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)?

    • Do support-related issues get treated in a special way?

    • Example: OceanHackWeek PR to pilot-hubs: 2i2c-org/infrastructure#564

    • Example: Outage reports such as 2i2c-org/infrastructure#524

    • If we add a support-related issue, do we remove another issue from the activity board?

  • 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?

    • Via Issues, GitHub Discussions?

    • Example: Yuvi’s infrastructure renaming question: 2i2c-org/infrastructure#570

    • How do we signal-boost them? (e.g. put in “needs review”, put in “needs discussion”?)

  • 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: 2i2c-org/infrastructure#549

  • 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?

2021-06-06#

Attending#

  • 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#

  • CSS (fiscal sponsor) update by Chris

  • Yuvi did his first mybinder.org deploy after 2 years :tada:

    • Working on reviewing other people’s PRs

    • Tooling is really nice which has made this easier to do

  • Sarah is working on a tool to make it possible to test mybinder.org deploys from PRs on forked repositories

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?

    • 2i2c-org/infrastructure#

    • https://docs.google.com/document/d/17Kj_FbtVMl32TEcfvCp18fF1SEiBjVOhCswdidUytgM/edit

    • 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

    • 2i2c-org/meta#216

    • 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 :-(

Skipped/Backlog#

  • 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)

2021-03-08#

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 ✔#

  • I have mostly been working with ICSI to define the contract that we’ll use

  • I have worked with the 2i2c founding team to more explicitly define our governance and organizational structure! 2i2c-org/team-compass#38

  • Doing a bit of biz-dev trying to refine the Managed Service Plan that we’re offering to people.

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 ⬜#

  • Z2JH security vulnerability in z2jh guide on how to setup a AWS EKS cluster to be corrected and communicated.

  • Changelog writeup for z2jh

2021-02-15#

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 artifacthub.io 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

2021-01-27#

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!

Yuvi#

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 2i2c-org/leads)

  • 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!

2021-01-05#

Erik#

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?

Geo#

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.

Chris#

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! https://2i2c.org/team-compass and please don’t hesitate to contribute anything to this that you think would be useful.

Contents