firefox development process changes

Richard Newman rnewman at
Mon Aug 11 21:11:36 UTC 2014

> My hope is that it won't take long at all to write a daily report: 1-3 minutes. You know what you worked on today, and you should know what you're planning on doing tomorrow. I would strongly encourage you to do these daily reports at the end of the day, not the beginning, since everything will be fresher. I'd like feedback on whether this takes more than 3 minutes and if so why and whether more tooling would help!

I think there are some invisible costs here. My personal perspective (and again, feel free to ignore this because I'm not on the desktop team):

* Switching into archaeology/update mode takes a big mental disjunction. I prefer to do that, and get a better picture of the state of the world, if I do it infrequently and deeply.

* My daily status updates would contain either (a) no real info, or (b) useless details, from the perspective of the vast majority of readers. If I found out something worth communicating today, _I already communicated it_, using an appropriate level of detail for the audience I sent it to. Trying to make one update suit a huge audience -- product, UX, support, engineering -- requires a lot of attention.

I like communications to be specific, targeted, and actionable. Status reports are none of these things, so they either waste my time (and aren't read), or waste my time and the readers' time.

* For daily updates to be stress-free, it needs to be 100% socially acceptable for them to be brutally honest: to have multiple days with the update "got nothing done", "spent most of the day arguing about status updates on IRC", "read emails and churned through bugs", "banged head against shitty docs".

Remember that people optimize for what you measure, at the time scale that you're measuring.

If you start measuring (whether deliberately or not) the impressiveness or consistency of daily status updates, you'll get impressive daily status updates -- even if that means that they're twisted truths ("I'll land this tomorrow so I have something to report") or the result of altered and sub-optimal behaviors (tackling smaller and simpler bugs, leaving the thorny ones to sit).

These are well-known risks of agile even at the two-week iteration level, let alone daily. I've seen some horrifically dysfunctional behaviors caused by agile work-loading and reporting mechanisms.

> One of the distinct advantages of daily status reporting is that you have an opportunity to make a decision about your work each day.

I would say that it's great to make a decision about what you work on each day, and that's really nothing to do with status reporting. I use Trello for this.

> Another goal of very lightweight and frequent status reporting is to make sure that other people on the team know what you're working on and blocked on.

I don't know about everyone else, but that's what I use IRC, Bugzilla, meetings, direct email, and mailing lists for.

More information about the firefox-dev mailing list