thanks for the tip Justin I'm glad that there's been some progress on this since I was last actively involved with the Incubator. and it's cool to see that the CouchDB bylaws have had some sort of influence on this!
I think it's probably a good idea that podlings are advised not to create their own community guidelines. primarily, because it's easy to get things wrong when you're so new to the Apache Way (in fact, a bit of backstory: the reason we made the bylaws for CouchDB is precisely because we managed to graduate the incubator with a very wrong set of ideas about how to approach consensus building and decision making. I joined the Incubator and mentored a few projects and taught myself the proper ways of doing things with a bit more experience under my belt, and went back to the CouchDB community and reformed how we did things. the bylaws were an artifact of that process) having said that, we have a number of very seasoned people on this committee, and I don't think there's a risk here re our community guidelines not being inline with how the ASF operates the sections of the CouchDB bylaws I think we could get the most value from are 3.1 Lazy Consensus (https://couchdb.apache.org/bylaws.html#lazy), 3.2. Discussion (https://couchdb.apache.org/bylaws.html#discussion), and the specification that Lazy Majority is used for non-technical decisions that move to formal voting. 4.1. Subject Tags (https://couchdb.apache.org/bylaws.html#tags) might be handy too I am not sure how apparent it is from the CouchDB bylaws, but they were designed as a tool to cut through long, exhausting arguments which were plaguing the community at the time. and in that respect they were quite successful we have already seen, these past few months, that when it comes to D&I, there is a major risk that discussions and decision making get out-of-hand even when the people involved have decades of combined shared Apache experience additionally, we're not a software project, so we're not going to be making any technical decisions. so, having some clarity in the form of an agreed upon and documented approach to non-technical decision making seems especially valuable On Sat, 18 May 2019 at 01:40, Justin Mclean <jus...@classsoftware.com> wrote: > Hi, > > And recently even those have seem to have gone out of favour as many of > them contained things that were not in line with how the ASF works or its > policies. Podlings are asked not to create them on graduation. > > For procedural things (voting and the like) I just point podlings to this. > [1] These were approved by the board. > > Thanks, > Justin > > 1. > https://cwiki.apache.org/confluence/display/INCUBATOR/DefaultProjectGuidelines > --------------------------------------------------------------------- > To unsubscribe, e-mail: diversity-unsubscr...@apache.org > For additional commands, e-mail: diversity-h...@apache.org > >
