And to give you an idea of details, here's a general description of the apache voting process:
<http://www.apache.org/foundation/voting.html> .. and an example closer to CSL, of a recent specification: <http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/4759a30ed73c5af8#> So in this case, they open up a formal voting process for a specific release (OpenSocial 2.0) against a specific revision with a list of patches, open for a defined time-period. People signed up with voting rights vote. Note also there are different kinds of votes. The standard one (for more important changes I guess) require at least three +1 votes. The lazy-consensus vote has a lower-bar. We essentially need to make the revision process for CSL as easy-as-possible to manage (technically and socially), but also one that leads to predictability for development. If anyone has any particular ideas of how to best operationalize this for CSL, I'd like to hear them. I suggested to Rintze, for example, that one possibility after 1.01 is to merge some of the repos so that patches can be more easily identified and isolated. Perhaps a new feature, then, would have a feature branch, and we could periodically collect a few to vote on, maybe some with lazy voting, and others with a higher-bar? Bruce ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
