There are docs to answer some of these questions. Avoid voting at all costs.
Seriously. Seek consensus. Offer a plan, and modify it based on input. Give actions 72 hours for input minimum, more if discussion continues. Voting is kind of anti-social. It is inherently divisive: somebody loses the vote. Feel free to *poll* for *opinion*, but PLEASE avoid votes at all costs. By way of example, I can only recall a few community votes in Apache Subversion over the past decade. We operate by seeking consensus. Now, rote items like adding PMC members are typically votes. Whether that process is "majority" or "vetoable" is up to the community. Subversion people start a discussion on a candidate on the private@ list, but if there is any negative feedback, we usually turn the conversation into "maybe we wait a bit for this person". Code can just be committed to trunk without having to stop and seek consensus for each patch. You only do that if the commit really changes something about the project (add feature, architecture changes, etc). Typically, release branches require a vote to merge stuff from trunk, during the stabilization leading to release. There are the highlights. We can talk more details if there are questions, or as we reach those points. Cheers, -g On Jun 14, 2011 8:31 AM, "Rob Weir" <apa...@robweir.com> wrote:
