firefox development process changes
benjamin at smedbergs.us
Tue Aug 12 14:37:44 UTC 2014
On 8/12/2014 10:15 AM, Gijs Kruitbosch wrote:
> The OP explicitly called out wanting status updates for every single
> backlog bug you're involved with.
With the automatic form that bwinton is implementing, right?
> 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).
As I said, that's something we're going to try and fix short-term.
> 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.
My experience is that my day varies significantly; some days still I
spend 4-8 hours doing reviews, and some days none at all. Some days I
explicitly decide to postpone coding because there are more
important/urgent reviews, and sometimes the other way around. As a
manager and as a team, I think it's helpful to at least write down the
decisions we made or plan to make about this kind of thing.
> 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.
So here's the rub. Managers are looking for a low-touch way to be aware
of work being blocked: reviews, needinfo, decisisions, whatever. Some of
that is encoded in bugzilla, but not all of it, and so we're trying to
find the lowest-touch way of marking those dependencies and calling them
out to the entire team, not just individuals.
Maybe status reports are not the right way to do it, but I think it's
worth a try.
> 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?
a) Maybe. Worth calling out if something eats a bunch of time, sure!
b) absolutely. I think one of the things we're trying to identify is
work that's happening which isn't on the backlog. One of the goals is to
make as much of that work explicit as possible.
> It would certainly be better if I could identify people by their
> names, and potentially teams as far as employees are concerned.
Yeah, I expect we'll be adding nickname support so that status updates
can tag @nickname for email pings. Maybe we'll try to pull other info
> 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. :-)
Maybe we need a different tag: firefox-desktop?
More information about the firefox-dev