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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
