sure thing, Gris. happy to wait On Sun, 19 May 2019 at 02:32, Griselda Cuevas <g...@google.com.invalid> wrote:
> 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 > > > > > > > > >
