firefox development process changes
gijskruitbosch at gmail.com
Thu Aug 7 16:43:00 UTC 2014
In response to this, I had some questions, which I was encouraged to
raise more publicly, which I am doing herewith:
On 30/07/2014 00:41, Gavin Sharp wrote:
> we're going to cap the size of the selected work based on historical
> team performance. The cap is a rolling cap that will adjust
> dynamically as team performance changes over time. This work will be
> the team's commitment. If committed work is complete, the team is free
> to pick up more work at your discretion, but not at the cost of
> committed work.
What does this mean in terms of picking up new work mid-iteration? Do I
need to resolve *all* committed work before picking up anything else?
What is the aim of this cap?
Assuming the aim is avoiding people picking up work and that causing
original (prioritized) commitment from being carried over and remaining
How much of the carryover from the iteration reports is really "new
work" picked up late in an iteration? (looking at the spreadsheets, both
work that I picked up at the start of the iteration and work that I
picked up on the last day gets marked as "Carry over" for the next
iteration, which I find confusing)
More practically, if you look at the commitments from this week's
meeting, the early meeting picked up 70% of the cap. Why is that?
Finally, I often run into the fact that I am blocked "mid-bug" on a
needinfo, review, dep/blocking bug, UX decision, ... etc. This is one
reason that I like to have several bugs "on the go" simultaneously,
because then instead of twiddling my thumbs I have alternative stuff to
work on. This doesn't jive with the cap, because now I can't pick up
more work. It was suggested that instead of picking up other stuff, I
should make (more) noise when I'm blocked so that GMC/management can
help get things unblocked ASAP. This raises two concerns:
- I'm worried this won't scale;
- Personally, I am hesitant to "complain" to folks "higher up" that I'm
blocked because I'm waiting on one of my colleagues (who are often busy
enough without being chased about their needinfo/review requests).
More information about the firefox-dev