This is a call for start using Bugzilla (or possibly JIRA) for planning
again. I'm aware that my fierce critisism about our previous habit of,
IMO, creating unrealistic release plans, might be one of several reasons
for our dereased use of Bugzilla for planning. Now I'm start to see the
need for more organized planning for keeping track on what needs to be
done to get real blocks (and other things) working.
So here are some ideas about how to get realistic plans:
* Plan at block and feature level: Or stating it negatively: avoid
unecesary dependencies. In the past we have stated things like: 2.2
should contain real blocks, VPCs and stable CForms. While it certainly
would be nice to have, these things are not dependent of each other and
it just complicates life by making it seem like they have anything with
each other to do. Much better is to have separate and as independent
plans as possible for specific blocks and or features. This will be more
helpful and easy to grasp for people who have the itch to implement
something we have talked about for a while.
* Create incremental and evolutionary plans: From our experience of the
long path towards real blocks (and other things), it is very complicated
to get any traction from plans that require us to e.g. switch component
management and invent completely new technologies before even get to a
point where we can start developing something that is useful in itself.
Deliver one useful feature at the time without needing start a research
branch makes it much more likely that we get somewhere.
* Avoid coupling features to a certain release number: While the habit
to write roadmaps for each release seem to work nice in some
communities, it doesn't seem to work in ours. Possibly because some of
our todo items have been to complicated and research oriented. For short
term planning, like deciding what should be part of the release a month
from now, coupling todo items to a release might be useful. But for long
term planning it seem less usefull as our interests might change during
the period. It is also common that we agree about something being
important, but no one actually have the itch to do something about it
(don't want to get Ralph going by mentioning the stabilization of CForms
;) ).
* Replan and prioritize: A plan only represent our knowledge, interests
and priorities at a certain point in time. As we and the world around us
develops, so must our plans and priorities. Also I think that when our
release dates start to slip (like a couple of years or so ;) ), it is
better to lower our requirements and schedule some of the items to
later, than to let the plan continue to slip. Remember: if a bug doesn't
get fixed or a feature doesn't get implemented, it doesn't have to mean
that we are a bunch of bad and lazy people without responsibility ;) It
might mean that the bug or feature wasn't that important.
WDYT?
/Daniel
