| Thread Previous • Date Previous • Date Next • Thread Next |
I know that for both Translations and Code, at one point they were *forced* to scramble and update their part because that was required to fix some breakage. Sorry, to be hand-wavy around the precise breakage that required completing that refactoring, but if you are interested, I'm sure Danilo, and Aaron or Tim can fill in the details.
I too forget the details but I don't feel the Translations team were forced by anyone in particular to scramble and update our code. However we did end up in a situation where we had to do so.
While I agree completely with what Francis advocates, I find no fault with how this particular change was broadcast. We got persistent reminders from outside the team and there was constant awareness within the team that we needed to move to the new model soon. There just happened to be enough pressure in other areas to keep us busy.
Michael went to great lengths to ensure that his work was backwardly compatible and that nobody was forced to do anything, and from my point of view I thought he did an incredible job. Not only did he come up with fantastic code, it worked first time in production, and didn't break the Code and Translations jobs.
Yes and no. As we now know, the compabitility provisions were masking a flaw: the bridge between the old and the new models was built on the very part of the old design that never applied to Translations in the first place--one of the very problems the new model fixes. We're lucky to have caught this even now, given how hard some of the buildfarm stuff is to test; we could have ended up with our jobs being quietly ignored for unclear reasons. We know how to get back on track, but that involves a change of plans for the model migration itself.
What can we do better in a situation like this? The job is too big to expect one or two people to go all the way in one haul. A feature branch alone won't cut it at this scale of change. Keeping affected teams in the loop didn't work out--for reasons that would be interesting to discuss separately, but for now I'll just say they are the problems you get with virtual teams and long-term goals.
What I think would work best here is to bring the virtual team back together for a "Wellington II: Return to the Buildfarm" sprint, to revamp the model across the board and meet Q/A criteria worked out in advance. Make the team non-virtual, bring the goals to the short term, go back to our "regular" work when done.
Jeroen
| Thread Previous • Date Previous • Date Next • Thread Next |
