Subject: why bother planning? (was Re: Bugzilla comments)
From: Paul Rohr (firstname.lastname@example.org)
Date: Mon Mar 12 2001 - 11:33:48 CST
At 04:08 PM 3/10/01 -0600, Sam TH wrote:
>> - Inclination/Time estimate: These only really make sense where
>> the project is driven by $$$. When I work on a project in my
>> spare time, I don't do stuff I don't want to do. It's that
>> And while the time estimate could be useful for planning, it
>> also only makes sense if you have committed time - I give hours
>> to the project when I have some to spare and feel like it. You
>> can't make any planning based on contributions like that.
>> [i.e., you can't sum the estimated hours for bugs scheduled for
>> next milestone, divide by 40h/week per developer and set a
>> release date from that - so why bother?]
>I agree here. I might say "I'll do this this week", but then be
>swamped with schoolwork, and not get to it for much longer.
>I don't know about Inclination, since I have no idea what that's
>supposed to mean.
>[for the perplexed: look at http://bugzilla.eazel.com]
You're both right. These fields are most useful for products which have a
paid staff. I still think they could be useful for an all-volunteer effort,
but so far I haven't convinced anyone.
These two fields are most useful when we have a clear sense of code
ownership -- ie, when someone steps up and says, in effect:
- This hunk of the tree is my code.
- I'm the person responsible for its current state.
- Some of it I wrote, some I inherited.
- It's *all* mine now.
- I want it to be really good.
- Please let me know *anything* you think is wrong with it.
- My goal is to (eventually) get *all* such problems resolved.
In essence, this is more about communicating a clear sense of pride in one's
work than anything else.
To some extent, the "volunteer vs. paid staff" distinction is misleading,
because being paid doesn't make you more or less *proud* of your code, it
just affects how predictable your available time is. I'm sure I'm not the
only one who's fiercely proud of my work on this product, right? And it's
not like any of us is being paid to spend 40+ hours every week on it. :-)
Having fields like these two helps *communicate* the work it takes to get an
issue resolved, and the likeliness that the work will get done soon. In
fact, I'd argue that this is *more* useful if you're a volunteer than if
Say I own a feature, and somebody files a complaint. If it's quick,
embarassing, and easy to fix, I'll probably take care of it right away.
However, if it's a bigger problem, or it affects a chunk of the code that I
don't like to work on, there's currently no good way to get *other people's*
attention on that problem.
However, if I flag that problem as:
Time remaining: 2 weeks
then I'm communicating *very clearly* how happy I'd be if someone would take
this off my hands, because I'll be focusing my attention on other issues
which are flagged like this:
Time remaining: 2 days
Time remaining: 4 hours
Does that make sense? The whole idea is to use Bugzilla to communicate
status, so that if someone else comes along and is looking for work that'll
really help you out, all they have to do is grab something you dislike.
PS: For completeness, here are Eazel's descriptions of these two fields.
This tells how much the current assignee likes the idea of fixing this
bug. If it's set to a low number, this will be one of the first bugs we
consider reassigning to someone else.
This is the assignee's best estimate of how long it will take to resolve
the bug. It represents the work remaining, not all the work on the bug.
Like all estimates, it's not perfect, but it should be updated as often as
possible to reflect progress.
Note that in our case, "reassignment" is a volunteer activity, too.
Somebody else "reassigns" the bug by claiming it.
This archive was generated by hypermail 2b25 : Mon Mar 12 2001 - 12:28:14 CST