@swalladge Thanks a lot for taking on the Lilac upgrade!
@adolfo Regarding Maple, what’s the target release date? I think we’d have to start the planning phase of the Maple upgrade epic no later than two months before the release date, but let me know if you think more time would be needed. (CC @demid, in case you have some input here as well as owner of the Koa upgrade epic )
maple.master will branch off from master on October 9th, exactly two months before the release date, December 9th. This makes October 9th the perfect date to start the process, because we’ll know what to target. But by “start the process” I mean at the very least having an epic created and a few discoveries in motion.
Maple will be a complicated upgrade, because there will be no support for edx/configuration. Assuming Grove will replace it for us, it will not only have to be working by then (which means coordination with @shimulch on BB-4199), but the Ocim frontend will need to be ported to it as well, and we will need to have a migration plan for everybody. If we guesstimate the work to be in the order of 900 hours (which even though more expensive than any other upgrade, it is still a rather optimistic figure), and that it needs to be done in at most three months, this means that from October 9th to January 9th we’ll need to spend around 300 hours per month.
That is at least 3 developers very nearly dedicated to the work. We need to make sure those numbers are in the spreadsheet.
Thanks @adolfo, that’s useful info to have in mind.
I added 300h for Oct-Dec to the spreadsheet, and that put us way above capacity for Q4. I haven’t done a full planning pass this sprint yet, but something will have to give (unless the new recruitment process allows us to increase the size of the cell much quicker than the current one).
Yep, that’s definitely an option and something we’ve done before.
I’m not sure about that. The risk of work not getting completed on time and/or up to standard seems higher in this scenario than when giving upgrade work to newcomers that already completed their trial project successfully. If we use it sparingly, the approach may work, though
Yes, these types of epics would be a good source of work for newcomers We’d just have to find/agree on a way to deal with sustainability implications. (The DevOps epics are usually on non-billable cell accounts, so if newcomers take longer to complete tasks than core team members would – which is not uncommon and understandable – this will impact cell sustainability negatively.)
Since Bebop has the most context on Grove-related epics at the moment it would make sense to see if we can find a way to move FAL-2081 to Bebop. As far as I’m aware, one potential option would be for @giovannicimolin to take it on (cf. this comment).
We need to give substantial & difficult work as trial projects (cf Recruitment: Trial projects & bounties ), otherwise we won’t be able to judge them. They might (and some will) fumble the work, but that’s the principle – we need to see if they can take it. Upgrade work, by its nature, isn’t urgent to one given sprint, if we plan ahead enough – when some newcomers fail at it, we can reschedule another task to do it again, from scratch if necessary.
A trial project that fails can be logged against the recruitment budget (cf also Recruitment: Trial projects & bounties ) – it will replace the onboarding budget in that case. Trial projects should be safe from a budget perspective (and it’s also meant to be the case for tasks given to newcomers btw - the difference between the time it took for a newcomer to do the task and what it would have taken a confirmed core team member is meant to be moved to the recruitment budget).
Thanks! Can I let you figure out where/who will take this on? Let me know if it ends up blocked.
We don’t have an owner for the Maple upgrade itself (SE-4957) yet. Since FAL-2081 and SE-4957 will need to be completed sequentially, at least to some extent, it might be possible for Serenity to own both epics after all. However, considering that the effort involved in the Maple upgrade will be larger than other version upgrades that we worked on recently, Serenity will likely need substantial help from the other cells, including their newcomers.
The blocking work from the Lilac upgrade is mostly done; there’s only one ticket left to complete next sprint.
The conversation about remaining work from BB-4199 that is blocking the Maple upgrade is still ongoing, but shouldn’t keep us from getting started with initial planning for the upgrade epic.
So we can continue the process of finding an assignee for the Maple upgrade epic:
@daniel and @gabor already had some clients and epics on their plates and recently took over additional ones, so they would likely end up spreading themselves too thin again by taking on the Maple upgrade.
@adolfo will need to focus fully on LabXchange going forward, and won’t have capacity for any other epic/project going forward.
@nizar is looking to take up the (non-cell) Developer Advocate role in the near future, so if he were to pick up the Maple upgrade now he’d likely have to pass it to someone else after while.
Based on these points it seems like our best options for taking ownership of the Maple upgrade would be @jvdm and @pooja. Would one of you be up for it?
Upgrade work that requires coding, testing, and bug fixing – yes, these are great candidate trial tasks, especially if we flag these issues early in the upgrade epic planning, so we have enough lead time.
But I wouldn’t feel comfortable with using the actual site upgrades as recruitment trials – not because they’re too hard, but because the timing is critical to the client and their users, and we could lose data or damage our client relationships if things go wrong.
@jill Good point that we don’t want a disaster for the actual upgrade on the production servers – but maybe they can do all the preparation work, up to and including a staging server upgrade, and preparing the instructions for a core team member to do the final operation on the production servers, after all the quirks have been ironed out?
I wish this came up for discussion earlier. For the past few sprints, @demid and I have been pushing preparation work for the upgrades whenever someone asked for an extra task, so all the remaining work it to upgrade the current stage/production servers.
Not sure there’s much to evaluate from having newcomers just upgrading servers (there’s a second implication: giving full access to production servers and extra credentials).
I was considering to take it, but I went on vacation and it ended up being assigned while I was off. Thanks for taking it up @gabor, and let me know if you need a reviewer or help with it.
@tikr Where do we stand in terms of assigning the Maple upgrade epic? The release working group has been reiterating their call for testing and contribution to the upcoming release, during the contributors meetup yesterday – are we participating?
@antoviaque We don’t have a confirmed assignee for the Maple upgrade yet. I was going to repeat my earlier ping towards the end of last sprint; but after learning that the LX project cell was going to be created this sprint I decided to hold off and get confirmation on this approach first. (Because I thought that merging the generalist part of Falcon back into Serenity might increase our options for getting the epic assigned.)
Anyhow, based on your update I went ahead and assigned the epic (SE-4957) – even if we need to change the owner again, this will hopefully help speed things up in the short term. Serenity does have a couple newcomers looking for tasks (ref, ref), so it seems like it would be possible to get started on some of the work (*) once a first batch of tasks has been created.
(*) One of the blocking tickets from the Lilac upgrade is not completely done yet, so branch prep for Maple may need to wait a bit longer.