firefox development process changes
gijskruitbosch at gmail.com
Mon Aug 11 21:08:00 UTC 2014
On 11/08/2014 21:45, Benjamin Smedberg wrote:
> On 8/11/2014 3:33 PM, Gijs Kruitbosch wrote:
>> Which paradoxically provides a reasoning why the Tuesday meeting was
>> eliminated, but not why we now should be spending time on on this
>> *every day* instead. Doing so (and I suspect this is the main reason
>> for the reluctance) is just as, if not more, tedious than a
>> once-every-two-week meeting.
> I'm surprised by this. Are you worried about the time it would take to
> *write* the daily status report, or the time it would take to *read*
> others' reports?
> 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!
It does take more than 3 minutes. Not least because Gavin's original
post explicitly asks to do them at the beginning of the day.
For one, looking up the relevant bug IDs for my reviews, patches
written, helping out QA with verification, etc. takes upwards of 3
minutes, especially on Monday because "yesterday" is now Friday, so good
luck remembering what you did 3 days ago (and/or what others did to bugs
where you were waiting on them)! Equally, planning for what you'd do
after the weekend seems nonsensical, as you won't know what your bugs do
over your weekend (which, inevitably include working time for some of
your colleagues in other timezones, on whom you're dependent for review
and needinfo - and that's without all the weekend hours many of us pour
into this project.
This is also why I think morning updates are probably more sensible than
evening ones, as (again) my colleagues work while I sleep/relax, and so
planning for tomorrow without taking their work into account means I
will probably have to plan again the next morning anyway, making that
part of the update useless.
Then on top of the time spent writing up what I/others did in bugs,
there's trying to remember whatever I've done that was not tracked in
bugs (that are in the iteration/backlog). Then there's articulating what
I'm doing today and/or where I'm blocked.
I didn't time it, but I fully expect I took 10-15 minutes to write
today's. But hey, even if I took 3 minutes, that times 10 working days
is 30 minutes, which is approximately how long the Tuesday meetings
took, so we're saving 0 time by switching from the weekly meeting.
> One of the distinct advantages of daily status reporting is that you
> have an opportunity to make a decision about your work each day. This
> isn't just about *what* you accomplished but also also about
> *deciding* what to do. That's not something you can do every two
> weeks! It gives me at least a great sense of control over my own work
> to review each day and decide what I'm going to do the next day.
I'm confused. The latest post here:
is from February. Are you using a different tool? Should I be looking
elsewhere? Am I just missing posts from people?
> 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. The trick is being able to very quickly scan the
> team's status at some point, and highlight the most important bits,
> which are usually the "blocked on" data and mentions of your own name.
> Those are improvements to the status reporting tool that I'd like to
> do soon.
But the "team" stuff is messed up. I see people in the "firefox" team
whose email addresses (and that's all the tool shows!) I don't even
On the other hand, I'm waiting on 2 reviews right now. Only 1 of those 2
people wrote something today - and they wrote it in the last few hours,
after I stopped work (well, ish) for today (hello, timezones!). So the
tool is effectively useless for me from the perspective this paragraph
tries to advocate.
More information about the firefox-dev