Hi Naomi, I'd like to propose an alternative approach, how about we first agree on a set of values we want to define the committee (and the Foundation on the D&I front), and the goals we want to achieve as a community. From there we can define guidelines.
To me guidelines need to be in alignment to the values we choose as a community and the goals we want to achieve together, that's why I am suggesting we define those things first. So, the succinct proposal would be to first define values and goals, then the guidelines. I also think we could benefit from allowing the creation of the dev@diversity mailing list first, so the committee has a space to collaborate and discuss these topics. How does this sound? On Sat, May 18, 2019, 8:00 AM Naomi Slater <n...@tumbolia.org> wrote: > 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 > > > > >
