Hi All,
Earlier today we had our fortnightly development retrospective. Given
that half the team has just gotten back from a work-week in Toronto, I
was not surprised to see that show up as a major theme :-)
The follow-ups from last time:
* We had a bit of discussion about our meeting load, but didn't find
any obvious candidates for trimming. We streamlined the Monday
morning meeting by using the waffleboard to drive conversation and
fill time between the "UX" and "Ops" components, which seems to have
been effective.
* We watched out for "train creep" when cutting train-73, and while
there were indeed fewer items marked "shipit" than there were last
cycle, we still had one for which we opted to delay the train.
* Our efforts to ensure clean, readable commit messages seem to have
been paying off, so please keep up the good work everyone!
New topics of conversation included:
* It's great to see us investing in the hard-but-necessary work of
improving our tooling, such as Sean's test runner change, but also
lots of other little fixes that we've been making recently.
* The Toronto work-week felt very valuable, and incredibly productive!
We talked a lot about whether we could successfully capture some of
that productive energy in an asynchronous fashion, and will likely
wind up trying a few things to find out. Key factors that may have
contributed to this feeling:
* Having a single, challenging problem to focus on as a group.
* Having Alex and Ryan Feeley's undivided attention to talk things
through with the team.
* Being able to discuss in a synchronous fashion, rather than
back-and-forth on IRC or email.
* The structure imposed by (an accelerated version of) the GV Sprint
process helped focus efforts and keep the week on track.
It may be worth us trying to capture the essence of this in an async
fashion, by e.g. doing a "virtual sprint" on Vidyo once a month.
* We'd like to move towards more of a Continuous Deployment model, at
least for quote-unquote "low-risk" changes like metrics tweaks or
styling fixes. We have some of the parts necessary for this already,
and should be able to move incrementally towards it by iterating on:
* The docker build infrastructure
* The metrics by which we determine whether a deploy was successful
* Generally making fxa-dev a closer match to production
* Our "flow event" pipeline has produced some early wins, but also
plenty of frustration as we discover new ways in which it's not
working quite right. This frustration is exacerbated by the two-week
turnaround when shipping fixes on the usual train schedule.
* One of the main reasons we follow a two-week train schedule, is to
give localizers enough time to translate strings. We could keep
this advantage while allowing more flexibility in other areas, if
we're more disciplined about cutting the initial tag for each train
on time, and more willing to make point releases afterward.
For the current development cycle, we will focus on the following things:
* Capitalizing on the energy and outcomes of the Toronto work week,
and ensuring we can translate all that into a pipeline of shipping
features.
* Cutting all the trains on the Monday and using point releases for
follow up work that we want to ship, rather than putting things in
"shipit" and holding up the entire train.
Cheers,
Ryan
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
