firefox development process changes
gijskruitbosch at gmail.com
Tue Aug 12 14:15:08 UTC 2014
On 12/08/2014 14:43, Benjamin Smedberg wrote:
> Perhaps this is a question of the level of detail people expect and
> want in a status report. I can't speak to what Gavin wants on his
> team, but for my team I really don't want that level of detail. In
> terms of team communication, I would expect:
> * that you spent two hours on reviews. Call out the big review for bug
> N because you know three people were blocked on it.
> * a half-day writing code. You wrote the test for bug N but none of
> the code yet
> * and the rest of your time got eaten up by miscellaneous stuff
> * You know that Y is blocked on a review, and you plan on doing it
> first-thing tomorrow morning. After that you've got a half-day of
> training and don't expect to write any code tomorrow.
The OP explicitly called out wanting status updates for every single
backlog bug you're involved with.
Reading your hypothetical status report, the only thing that would be
useful to me as a reader is the things that involve explicitly
identified people or bugs (which, because the status tool doesn't
provide descriptions of bugs of any kind, I'd need to open to check to
see if they were useful/interesting to me). The rest of it sounds like
"I wrote code, did reviews, and the rest of my time was eaten up by
misc. stuff.", which would apply every single day, and is therefore no
longer signal, just noise.
Regarding the blocking on reviews for tomorrow: if I manage to review
things within 24 hours, I don't think I need to do any messaging (unless
there is some cause for urgency, e.g. security issues). If I don't, I
think this information is best relayed in the bug, directly to Y (who
might then want to pick a different reviewer), rather than lost in a
status report on another tool.
>> 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).
> I'm not sure what this means.
I'm not sure if this makes it more clear, but: sometimes I do stuff
during the day that either (a) doesn't involve bugzilla, or (b) involves
bugs which aren't tracked on the firefox desktop team's backlog (for
whatever reason). They still take time, and some are still important to
others, so they should still go into my status reports, I think?
>>> 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
> Is that bad? Are they not working on Firefox at all? The explicit goal
> of the tool was to make it possible for volunteers to integrate in
> with the teams more effectively, so that employees can know what
> volunteers are doing.
It would certainly be better if I could identify people by their names,
and potentially teams as far as employees are concerned. I also think
the "firefox" team would be more useful if it were more finegrained than
"Firefox" - it's certainly much bigger than just desktop engineering/ux
right now. The thing that gave me pause was actually an @mozilla.com
address which I didn't recognize. The only volunteer I've seen use the
status tool is Manish, and I know who they are. :-)
More information about the firefox-dev