[Support process] Scheduling downtime for a hub

[sgibson91]

Context

In a recent chat with @yuvipanda, we touched upon how it is sometimes difficult to push out upgrades/improvements when that would result in downtime for a hub/cluster. One recent example was cloudbank being in constant use when we tried to update the storage type.

We need some kind of process that would allow us to schedule and announce that a hub would be unavailable for a period of time while disruptive maintenance work is underway.

We'd need:

• a method of scheduling downtime with Comm. Reps. to avoid deadlines - something like a shared calendar? But also a communication channel for saying "we want to add something to the calendar" - maybe just emailing the rep from the support email is ok?
• a method to communicate the scheduled down time with users, probably some kind of mailing list and announcements banners on the hub homepage (I think I've seen an issue about the second one somewhere?)
  • EDIT: It's this issue and the linked PR Visual UX: Make the announcement text a banner jupyterhub/jupyterhub#2566

And lastly we need someone to do all that work, which is related to #420

Proposal

No response

Updates and actions

No response

[choldgraf]

re: communication channels, I think a mailing list is the easiest short-term solution. Longer-term, I'd love for us to have a more dynamic place where users give more attention, but in the meantime I think an old-fashioned listserv is the most reliable path to others.

I'd propose that we do:

• Create a [email protected] Google Group
• Put the community representative for each community on that group as part of the community onboarding process
• Tell them that any "official" communications with community reps will happen via that group
• Allow them to post to the group as well

What do others think?

[damianavila]

I guess the email list would be useful if we want to do maintenance as a whole (it could be also useful in major disruptions) but how do we handle the communication with specific communities (I would bet that would be most of our cases).
In that scenario an email from support to the comm representative is OK, IMHO, to start planning the downtime.

[choldgraf]

I think that this is why it's important to have a clearly-defined Community Representative with an e-mail address for each. I agree we want to be able to get in quick touch with these folks if need be. Right now this is "informal" and based on folks that a subset of us have already spoken to (e.g. we already know and will respond to Jeremy from UToronto, even though he's not technically defined as the community rep)

[yuvipanda]

I think we'll most likely always have per-community notifications about downtime rather than something 'generic' to everyone. Even for something that affects everything like z2jh, I think we'll do it in batches rather than in one go.

I think a canonical list of community reps + a process to email them is a better fit than one group with everyone.