Open Stack

Gregory Holt wrote:
> And, on that note, I'm with what Rick said. Major stuff should be decided on early; minor stuff up to the freeze point; bugfixes always go; make sure blueprints exist for each new feature so documentationalists can do their work. Who decides what's major and minor? Well, the community I guess. Whether or not it'll break anything else around it. And Rick would get the final vote I'd guess.

+1.

As a sidenote, tracking (some of) the work that is being done is not
just for "documentationalists", it's for everyone else too.

One of the challenges of global/virtual teams is to fight confusion and
fragmentation by generating a lot of clarity and shared understandings:
communicating what we are working on, and the status of that work is
helpful for everyone (outside *and* inside the development team). It
will reduce confusion and fragmentation of effort, and will also reduce
the amount of interrupt-intensive communication from people asking you
about the state of your work.

The idea is to have a sufficient amount of processes and structure in
place to allow us to work seamlessly, and certainly not to refrain
people from landing nice features by adding unneeded bureaucracy.

This is work in progress, and we'll review those processes regularly,
and at every design summit, so nothing is set in stone. At this point
I'm trying to add clarity by clearly documenting a process in the wiki
(rather than having an unclear and partially undocumented process in
place, with people struggling to find out what they /should/ do).

Cheers,

-- 
Thierry Carrez
Release Manager, OpenStack