We’re discussing how to split the SE-1834 Ocim containerization epic into smaller projects, so that we can spread the capacity and learning required for implementing this major change across all of the cells. It’s a fantastic DevOps opportunity – incorporating kubernetes, terraform, Tutor, Docker, and more. I’m stoked.
It’s a non-billable, non-cell project, so won’t hurt cell sustainability. It’s also community contributions, so can count towards core-committer time. But we still need to ensure that we plan and estimate the work carefully, to keep the scope tight, coordinate the work between cells, and parallelize what we can so we’re not blocking each other. Plus, capacity is still an issue, and so we also need to plan to bring newcomers into the work.
The most pressing on the list, for now, are creating the image builder and improving Tutorraform (including renaming it, as requested by Regis). I think they’re safe to handle separately. Plus, it’s the only clear way of splitting the immediate work between epics that I could find.
The general discovery is this one (for which I had already asked for comments a few weeks ago). I recently rewrote it to be based on Braden’s work on Tutorraform, including his suggestion of The Three Major Pieces - hence why the first three items in my proposal.
As project lead, I’d rather have it move forward than wait on my cell’s capacity. But I’m not ready to give the work up entirely. I intend to not only propose that Ocim (and its accompanying deployment mechanism) be owned by a single person, I would like to be that person. And that’s only interesting to me as long as I can work on it myself.
So. There are really only two epics up for grabs that need to be worked on now. The image builder and Tutorraform. One I’d like Serenity to keep. Given @jill’s enthusiasm, it makes sense for the other to go to Falcon. Jill, any preference?
PS: I’m now filling in for Sid as Serenity’s recruitment manager, which goes counter to my objective of focusing on less things in the short term. But it sure puts me in a good position to solve the problem in the long run.
This is an update to the thoughts I posted above. Something of a reversal.
As I stated previously, the main problem is that Serenity will not have the capacity to handle this on its own. It wouldn’t have the required sustainability, either, if it weren’t for the fact the epic is accelerated.
However, and this is what changed since my last post here, this sudden lack of capacity has had a large impact on my own sprints. I was already vying to reduce stress and improve efficiency by looking for something to focus on - and things have gone exactly in the opposite direction, unfortunately.
So, to keep it brief, I’m now looking for somebody to replace me as epic owner on SE-1834. (I’ll also be closing/relinquishing any planned or ongoing Ocim tasks, and will be dropping the devops specialist role, but that is for another thread.) I’ll continue as build-test-release chair, but only as a communication facilitator, so I’ll need whoever owns the epic to help me find assignees until Lilac is out. After Lilac, I’ll be opting out of release work entirely, and I suggest whoever takes this epic on should probably start attending the meetings.
Pinging @jill specifically: interested in taking it all on?
It would be pretty important for whoever takes on SE-1834 to be in the loop on all matters BTR and Tutor. Ideally, that person will attend the bi-weekly meetings (including the Tutor maintainer’s one), but I can imagine having a lieutenant that can would also work. Which is to say, if you can find an epic reviewer willing to do that for/with you, it has a good chance of working.
I’d have suggested @jill be just that reviewer, but I figure the meeting times are just as bad for her as they are for you. Maybe @raul?