openstack team mailing list archive

[Rick Clark <rick@xxxxxxxxxxxxx>]

I think there are some misunderstandings that need to be cleared up
before the thread goes any further.

here are some facts as I see them:

 * We are still in the process of documenting process.  (Don't get too
worked up over something that you don't know if you hate yet)

 * Only major features require blueprints created upfront.  (Any major
feature needs to be discussed with the development community before it
is implemented.  This is essential to the way we are running this project.)

 * I would like to have blueprints created retroactively at merge
proposal time, if necessary, for minor features. (Blueprints let us
track new things in the release so we can ensure release notes and
documentation exist at release time.  They also give us a way to let the
business guys communicate to partners what is going to be in a release.
If we don't tell them what is coming, we can't complain if they get it
wrong.)

 * Bug fixes never require blueprints

 * Blueprints are lightweight. (Blueprints do not have to conflict with
an agile process.  You can create a very light blueprint and spec, so we
can track a feature and add specification detail when you implement it.
 We are not expecting 25 page waterfall like software specs.)

 * Our processes resemble, but do not copy Ubuntu's. (Since many of us
came from Ubuntu, we are very familiar with their processes, and where
they are broken.  I used some of their process as a starting point
because I had to start somewhere, but we are trying to improve on them.
None of us think that Ubuntu has perfect processes or that they are
necessary applicable to our project.)

 * Our processes are alive and you can influence them.  (They will
evolve to be less intrusive and more efficient.  But we want to make
small changes during each release cycle, rather than large changes that
do not allow us to measure the effect of each change. This is Thierry's
(our release manager) first release.  Let's let him figure out things
and give him a chance to suggest changes that improve our process. And
give him your feedback)

 * Processes have a purpose. It the responsibility of all of us to make
sure that process does not get too heavy.  We are not trying to do
waterfall.


Rick

Attachment: signature.asc
Description: OpenPGP digital signature