> Just as an aside, the preference is for Apache projects to discuss their way > into a decision, rather than appeal to the process. > > Ideally, people should chat about things on the list, until someone does > something about it. If no one comments on the commit, then the decision is > made. We call this "lazy consensus". > > The key to this, of course, is that all the commits flow through the DEV > list. The commits are part of the development discussion too. The only part > that matters, really :) > > The Jakarta project tends to be a bit vote-happy. Many Apaches consider all > this voting slightly scandalous. Outside of a release, voting is seen as a > sign that discussions have broken down. Following the formal process is > considered a last resort -- what you do when discussions don't seem to be > working, and the team is not of one mind. > > A release is a little different. Since there are different grades of release, > a release will always require a vote. But these are usually majority votes, > and a -1 is not a showstopper. (Though, the goal is always for the members to > be unanimous, or to find a way for them to become unanimous.) > > The bottom line is that a project is not a government, it's a team, and a > team should be of one mind.
Well put. Voting on releases makes sense and the lazy consensus seems to work well on projects I've been involved with. Right now I notice that the JIRA issues are not sent to the dev list. Nor are the checkins. Is that going to change? > -Ted. sean
