Serenity: Looking for a new devops specialist

I’ve given this some thought (justification below), and decided that I’d like to relinquish the devops specialist role. The short of it is that we’ll need a new one, @serenity. Please volunteer. :slight_smile:

Why?

I’m stretched too thin. I was already vying to find focus so as to improve the quality of my work and reduce stress, and having had to take on recruitment was the straw that broke this camel’s back. As it stands, I’m responsible for:

  • Serenity Recruitment
  • The Community Liaison role
  • The BTR working group
  • The SE-1834 epic, aka The Whole Move Towards Containers
  • The SE-3741 epic, aka MIT, LTI, and Blockstore
  • The SE-1848 epic, aka Libraries v2 in Studio
  • The SE-774 epic, aka Clustered Redis
  • Mentoring @jvdm
  • A handful of devops-related tasks that have been spilling over so often I’m losing sleep.

I’d like to reduce this to at most:

  • Serenity Recruitment: it’s the most important thing I can do to reduce Serenity’s capacity issues - issues that are probably having the same detrimental effects on other cell members that led me to write this post. I can keep it forever, if @sid doesn’t object when he comes back.
  • The Community Liaison role: something that is also important and that I’m comfortable context-switching to and from.
  • SE-3741 for the next couple of months, and SE-1848 once it comes back from the dead. Both are Libraries v2 work, which I was originally excited to work on exclusively - the latter of which edX sadly delayed last year, but it’s looking like it’ll come back soon.
  • Mentoring @jvdm, which as been a pleasure and a great help towards SE-3741.

I’ll only keep the BTR chair position as it would not look good to just up-and-drop it. But I will step down once Lilac.1 is out the door. Hopefully the future owner of SE-1834 will continue participation in the group. For that and other epics, I’ll ping people individually on the corresponding tickets.

Weren’t you going to focus on Ocim?

Changed my mind. Due to the way sustainability and capacity work, internal epics always get the lowest priority - even when accelerated, as I recently discovered with SE-1834. It’ll always be uncertain how much time is available for them. This would make it impossible to reliably focus on it, so I’m no longer interested in heading the effort.

1 Like

Addendum: I’d like to try something else, too. @tikr, you might be able to offer some input, here.

I want to reduce my stated capacity from 40h/week to 32h/week, primarily as a hard-coded buffer to help mitigate the fallout from mis-estimation. What I’d like to happen as a result, is:

  • I’ll be officially on a 4-day week, taking off either every Friday or every Wednesday (haven’t decided which, yet).
  • On the day I’m off, I have the option of taking on a stretch goal I find particularly cool, to assist in firefighting something I’m knowledgeable about, to push forward a commitment that would otherwise spillover, or… to simply be off.

If it reminds you of the fabled Google 20% time, it’s intentional. I of course wouldn’t get paid to work on any old thing I come up with, but it would give me the intra-sprint freedom to help out wherever I’d be most useful.

What’s the flip side? If there’s no stretch goal or additional work I can help with… Tough luck; better go feed the birds.

Objections?

3 Likes

Just to close the loop here as well, we had a conversation about this on Mattermost and reduced @adolfo’s capacity to 32h/week as a result.