Greg Stein <gstein@gmail.com> writes:
> IMO, the concept of a date is corporate-speak. The proper mechanism is
> a status file of open items, along with the open issues (oh, and the
> idea of an issue for all work items is also corporate). Then people
> focus on the file/issues and work that to empty. *then* branch.
>
> Note that posting a weekly summary of 1.5 issues, along with that
> status file is a great way to "surface" the info so that all devs can
> see what is left. If that email can also cover progress, then devs can
> also see/feel like stuff is happening.
>
> This is more akin to agile dev than classic feature&date product
> delivery, which usually fails anyway.
:-)
I think you're right that a date is often "corporate-speak", but
that's when it's treated as a hard deadline -- in the sense that
dropping features or letting quality suffer would be be accepted to
make that date.
Mark is doing something different, though. He's trying to focus
development by saying "We could make this date, if we focus on the
issues we have listed right now, and let that date influence triage
decisions. Let's go for it!"
So if setting that goal makes us more likely to branch on Oct. 12th
(or anyway branch sooner than we otherwise might), it's a help. It
works, for me at least. Having a date in mind helps me focus, because
it reminds me that when we big new features with lots of surface area,
triage is an inherent part of actually shipping. The date gives me
something to guide triage decisions; I'm glad to have the date.
I think that's all Mark is doing. You're right that we should mainly
focus on the outstanding issues, but with new features, you can just
keep improving them forever if you don't have *some* sense of when you
want to ship.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 1 21:19:43 2007