firefox development process changes
gavin at gavinsharp.com
Thu Aug 7 18:55:33 UTC 2014
Thanks for the feedback, Marco - sorry for the lagged response!
(Other) Marco has already made improvements to the estimation
spreadsheet for next time around, keep that feedback coming if you
For status updates, it's probably useful to start with the primary
goal: having an easy way for everyone on the team to get a detailed
look of team progress on the committed work in a given iteration, at a
higher frequency than once a week.
A secondary goal is to having a way to expose the blockers to
productivity (e.g. code review, external dependencies, unanswered
questions, unclear objectives, PTO, etc.) without needing to review
activity for every active bug in Bugzilla. Staying on top of my
bugmail is hard enough already :)
The alternate proposal you suggest sounds like it would satisfy the
primary goal, but would not really satisfy the second, in that there's
no way to explain the reasons why a bug is blocked. That's what we
proposed a "what's blocked" field in the text status updates. We could
do a combination of both, certainly.
Hopefully that helps clarify the motivation - I will circle back and
come up with a revised proposal which hopefully addresses all of your
concerns. If you have any further ideas, let me know!
On Tue, Aug 5, 2014 at 2:47 AM, Marco Bonardo <mbonardo at mozilla.com> wrote:
> I think most of the changes are great, but I have some feedback
> On 30/07/2014 01:41, Gavin Sharp wrote:
>> - All estimation will be performed asynchronously via a Google Docs
>> spreadsheet, and points will be reviewed for outliers which can be discussed
>> separately. The goal will be to have all work estimated by the planning
>> meeting (between Thursday and the following Tuesday).
> I think the spreadsheet should somehow be improved for this, I had issues
> with scrolling it to see my column and I couldn't even resize the bug
> descriptions to see more columns cause it is locked. It was painful.
>> - We will eliminate the Tuesday status meetings entirely. In their place,
>> we will ask all team members to provide daily updates via bsmedberg's status
>> tool. Updates should be short and submitted at the beginning of your day,
>> and mention what you accomplished yesterday, what you plan to do today, and
>> anything you're blocked on. Your updates should include specific status
>> updates for each of the bugs that you're committed to: "work in progress",
>> "in review", or "landed".
> I'm very unhappy about this. As a contractor I already have to keep my
> hourly and weekly tracking (luckily there are nice online tools for that),
> and that's painful enough, having to also copy it out everyday would make me
> really sad. Moreover I don't like the feeling it gives me, I know it's done
> with very positive purposes, but I feel like not being trusted anymore.
> I think it's also too much fine grained to be useful, you should look at a
> bunch of updates (not well formatted to do that efficiently) and moreover
> once you read "work in progress" you must still ask directly to the person
> if that is 10% or 90% done. How is that an improvement over what we have
> today (I already see in the spreadsheet which bugs are resolved).
> My opinion is that this will put lots of burden on devs with a very minor
> I suggest instead we do something similar to the new point estimation, for
> each backlog row provide a status column we can change, it will have
> 10-100%/review/landed options, and we will keep them updated daily. It's
> much easier and quick for us, you get an idea of the whole situation in a
> single look, and won't make me sad (the most important thing :) ).
> firefox-dev mailing list
> firefox-dev at mozilla.org
More information about the firefox-dev