Sprint Plan 1 for Image Management Q3 Goal

[yuvipanda]

Where are we now in relation to our goal?

Just getting started!

What is the biggest uncertainty or obstacle to reaching our goal?

• Be more specific on how to measure our primary metric of success, and do so fairly effortlessly
• Figure out a process that can work within a 2 week timeline

Sprint 1 should be primarily focused on testing out this specific proposed process and see how it goes.

What should we do in the next sprint to learn and make progress?

This goal is very broad, so there will be a lot of small things we can do to achieve it. This presents a challenge, as we need to prioritize what would actually help, and learn from that. I propose the following loop:

1. Identify a specific class of issues that prevent research communities from being able to self service themselves
2. Pick a single specific community that has had this problem, and work with them closely on solving this class of problem for them. This would involve deployment changes, upstream work, etc.
3. Within the sprint, try to deploy to them a solution for this class of issue.
4. Give it the length of another sprint to see if our solution does in fact solve that class of issue, and iterate. If it does, work on deploying it to more communities!

There are several issues here, such as:

1. Need to find a community partner to work closely with each sprint, and this might be hard.
2. We need to deploy a specific change to a community within a sprint, which might be hard.
3. Our proposed solution might actually cause more problems!

However, I think there are some great advantages!

1. Lets us move fast, without breaking things for many communities! By working closely with a community champion from one community, we can make sure that breakage is limited.
2. Working with a specific community lets us see the positive effects of our efforts quickly, which is very rewarding from a morale perspective
3. We do have a lot of goodwill with our communities, and many of our community champions are well versed in this problem space. This allows us to take advantage of this resource.

Let's try this out and see how it goes.

Problem to tackle

To recap, our current (but changeable?) definition of success is:

Number of support requests per month about image management goes down by 50%.

The class of issues to tackle is Some subset of users want custom images, and allowing them to do that requires support interaction. Here are some example support tickets that characterize this problem class:

1. https://2i2c.freshdesk.com/a/tickets/386 has a lot of information about why this is important and useful
2. https://2i2c.freshdesk.com/a/tickets/796 which led to LEAP Cluster: Temporary fallback option for all images #2742
3. https://2i2c.freshdesk.com/a/tickets/798, where some users needed a newer version of one library, leading to VEDA: Update pangeo-notebook image #2727 but that broke jupyterlab-git for other users.
4. https://2i2c.freshdesk.com/a/tickets/794
5. https://2i2c.freshdesk.com/a/tickets/778 (and many similar), where the testing can be done instead.

There's more, but this is a decent sample.

Given the large amount of tickets here involving LEAP, I propose LEAP is the community we work with for this sprint. I'll reach out to @jbusecke separately as well, but I think it is doable.

What do we expect to happen (hypothesis)?

The hypothesis to test is:

Deploying jupyterhub/kubespawner#735 to LEAP hub and providing guidance on what images are available will eliminate this class of support ticket completely from that community

We can do the intervention during this sprint (get the change deployed, provide guidance) and test this measure over the next few sprints to see if it had the desired effect.

Sprint plan for this sprint

Upstream tasks

Beta Give feedback

1. Allow end user to select a choice different from list of available choices in profile_list jupyterhub/kubespawner#735
   new +1

Infrastructure tasks

Beta Give feedback

1. Document policy for deploying unreleased versions of packages in the hub image: when, how and why. #2800
   4 of 4
   +0
   
2. Deploy the change to the LEAP hub, working in concert with the community champion, and enable allowing end users to specify the image they want to use. Setup the profile list to allow a user specified image for leap.2i2c.cloud - for all server options #2146

Measurement tasks

Beta Give feedback

1. Tag all image related support tickets that come in #2767
   0 of 3
   +0
2. Measure what images are actually used by a JupyterHub community #2804
   +0

Guidance tasks

Beta Give feedback

1. [Docs] Create documentation on how to choose a tag for pangeo-docker images #2793
   4 of 4
   +0
   

What actually happened, and what did we learn? Did we confirm our hypothesis?

[jmunroe]

I agree LEAP is the source of a lot of tickets, but how many of those are image management requests?

There will be a number of new communities (~ 20) coming onboard over the next several months associate with the Catalyst Project. If we can work towards relatively few support related tickets for image management that sounds like a great win.

[yuvipanda]

me and @jmunroe caught up over a sync video call. We're going to try this process out as written so we can try the goal sprint process for Q3 and go from there.

[GeorgianaElena]

@yuvipanda, I've opened #2827 to track the work in #2699, if you want to add it to the sprint 1 plan here.

I will add it to the appropriate boards now and then close it.

[yuvipanda]

Thanks, @GeorgianaElena. I think we need to have a way to track 'long running work' that isn't directly tied into the sprint. I'll try figure something out for the next sprint.

[damianavila]

Generally, I think we should use the pre-existing Eng & Prod board (although with some updates/changes): https://github.com/orgs/2i2c-org/projects/22/views/25.
Specifically, we should use the binderhub-specific board (also it needs an update): https://github.com/orgs/2i2c-org/projects/33/views/1
We might also, and alternatively, introduce roadmap views in the Sprint board (or another sort of view) so we keep everything in just one board.

[damianavila]

Sprint ended successfully, IMHO.
There are still a few issues that will need a follow-up on the next sprint cycles (measurement, tagging, and docs).