Two points in addition to Carsten's: It states that "new features" need to be voted before committing. I believe that this is either unpractical (and sure not happening ATM) or/and not precise enough. Perhaps "major new features" would be better, but then, what's "major"? OK, it's only a guideline....
I would say that "anything that changes the contracts" has to be voted. New features that are added sideways, don't (say scratchpad or scratchpad blocks). But anything that enter the trunk should be voted.
Let's stick to contract or API changes of released versions requiring a formal vote. New stuff - I honestly don't think so.
the part that indicates what to do with patches is too much to place there. I would remove it.
OK - will look into that.
the part of new subprojects as well. if somebody asks, we send them to incubation right away.
How does other people feel about this? Most commonly, an incubating project needs a destination PMC, so we would be involved some way anyhow.
Thanks,
</Steven> -- Steven Noels http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/stevenn/ stevenn at outerthought.org stevenn at apache.org
