Re: [Monotone-devel] Project Management

[Rob Schoening]

I don't disagree. 

 

Really I was just suggesting that a minimal sort of "project management" could be accomplished simply by adding a "Roadmap" page in the wiki.  Some short articulation of features prioritized loosely in some temporal fashion that expresses where Nathaniel, Graydon, et al see this thing going over the near-term and long-term.

 

No ceremony or odious constraints required.

 

RS

 

On 7/19/06, Nathaniel Smith <address@hidden> wrote:

On Wed, Jul 19, 2006 at 05:01:41PM -0700, Rob Schoening wrote:
>    even without any tools, a one-page roadmap that identifies upcoming
>    releases and identifies features/fixes as targeting one release vs.
>    another would be very nice.  my guess is that this kind of basic plan
>    would do more for adoption of monotone than most features would.
>
>    * no need to commit to schedule
>    * no need to assign tasks
>    * no need to introduce any ceremony
>
>    just a statement of broad consensus among developers and users about the
>    road ahead.

The problem with this is that time-based releases just turn out to be
superior to feature-based releases.

The problem is that for a free software project, the actual rate
people hack is basically determined by external factors that have
nothing to do with the release schedule.  Occasionally in a
feature-based release process, people will make an extra push to get
particular things finished up so the release can happen, but even when
this does happen, it quickly acquires that nice Death March feel,
which isn't really helpful for productivity in the long run.  In
practice, when the scheduled work and the actual work differ, the
schedule is what breaks, and releases get pushed back.

The problem with _that_ is that you have a bunch of good code already
written and tested, but you end up holding it hostage for other code
that hasn't been written yet.  The philosophy of time-based releases
is, well, if code is going to go at its own pace anyway, we might as
well just make sure that it gets to the users hands as soon as
possible.

Then, as a nice little extra effect, in those cases where people _do_
change their work plans in response to the release process, it's
because they have some cool feature that they really want to get in
under the deadline -- and racing time this way is much more fun than
slogging through a pile of dreary work that Has To Get Done Before We
Can Release.  (And if you don't make it in time, there'll be another
release next month -- no problem.)

-- Nathaniel

--
/* Tell the world that we're going to be the grim
  * reaper of innocent orphaned children.
  */
-- Linux kernel 2.4.5, main.c


_______________________________________________
Monotone-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/monotone-devel