firefox development process changes

Gavin Sharp gavin at gavinsharp.com
Mon Aug 11 23:10:35 UTC 2014


It was perhaps a bad idea to use the short answer.

I would like to clarify some things:

* The rollout of the "daily status updates required" requirement is on hold
while we sort out some details (we're discussing the content of the updates
as well as tool improvements), as I mentioned previously in reply to Marco.
I should have communicated this more clearly in this thread.
* Speculation about what effects the requirement will have is somewhat
premature, particularly in the absence of details of those requirements.
* We WILL NOT be asking for "do the same reports you've been doing with
bsmedberg's tool, but daily"
* We WILL NOT be asking for a level of detail that would require Vidyo logs
and local bash histories
* The status updates we're asking for should generally not take you more
than 10 minutes to complete
* We WILL try to automate collection of some info (and encourage developers
to do so as well)
* There WILL be information required in the updates that can't be fully
automated ("what do you plan to do in the future", "what are you blocked
on")
* The desktop team is DEFINITELY way cooler than the mobile team and our
status update regime will want to make rnewman work on desktop

Gavin


On Mon, Aug 11, 2014 at 2:11 PM, Richard Newman <rnewman at mozilla.com> wrote:

> > 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20140811/d18c75f1/attachment.html>


More information about the firefox-dev mailing list