To be clear my email was not targeted at Marvin. We all know how hard Marvin has worked to create the clear policy documents I talk about here. I hope Marvin knows me well enough to recognize my debating style. This is not about *him* it's about the impression of the top down rules you describe below - as you seem to be implying that should not exist in the Apache Way apart from a few immutable areas and I agree.
Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -----Original Message----- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Thursday, January 8, 2015 9:25 AM To: general@incubator.apache.org Subject: Re: What is "The Apache Way"? On Thu, Jan 8, 2015 at 11:01 AM, Ross Gardler (MS OPEN TECH) < ross.gard...@microsoft.com> wrote: > WTF? There have been presentations about the apache way at every > ApacheCon for about 15 years (twice in most years). I personally give > 5-10 such presentations a year (sometimes public sometimes not). I'm > sure many others here do the same. > > The Apache Way is really simple. There are very few immutable rules > but anything that undermines those rules is not part of the Apache Way. > > The problem is not a lack of clarity its a lack of agreeing what > does/does not undermine those few immutable. The way we get around > that is to have a group of members who define it and take any action > necessary to ensure the Apache Way is protected. > > Those members can become IPMC members and help incoming projects learn > the immutable rules and how to evaluate whether an action will > undermine those rules. > > There is a process for building consensus around what is and is not > acceptable. There is an escalation process if consensus cannot be reached. > In the IPMC it goes... > > PPMC -> Mentors -> IPMC -> Board -> Members > > In TLPs it is similar: > > Community -> Committers -> PMC -> Board -> Members > > Nobody expects the PPMC to understand. Everyone expects Members to > understand, which means everyone expects Mentors to understand (see > how it is designed to be flat?) > You can become a member without ever living through a commit veto, or a nasty argument about corporate (over)involvement, or any number of other critical test cases of whether a community is, in fact, successfully putting the principles into practice. This wouldn't worry me so much except that I fear that (rarely) some members who have become mentors don't even recognize when something is happening which calls for them to call for backup. > > This is not a top down organization where rules govern what we can do. > It is not the boards job to define policy, that's the members job (and > the IPMC is mostly members). The board are the end of the escalation > chain, they break deadlocks only (and approve policies defined by the > membership). > > In my experience, there are some people who consistently act as if > there is some sort of top-down flow of rules. (In fact, in some cases, I would even count myself as one of them.) The usual source of floods of email on this subject is not the community principles of governance, but rather the legal details of releases. Some people 'round here think that's it is very important that the contents of NOTICE files are completely correct. Some podlings have achieved extreme frustration in this area, especially when some of those people disagree about what constitutes 'correct'. So, when Martin writes what he writes, I'm reasonably sure that what he's looking for is not a rule book of how to run a consensus community, but rather clear, complete, and non-contradictory documentation of how to produce a proper release. I have always had a sense that, at the VP Legal level, there is a sensible application of the legal principle of _de minimus_ -- that, in fact, little problems with this stuff are just not material. But, if I am right about that, I feel pretty clear that this does not get communicated downwards. Here's where I come in as a legalist: at the end of the day, a PMC is a legal formalism. The board delegates certain legal authority (notable, to make releases) to the PMC, and appoints the chair. The IPMC thus is a complex device: on the one hand, it is the legally constituted PMC with responsibility for the releases of podlings. On the other hand, it has spent the last few years trying to find ways to push authority downwards into the podlings. The pTLP business asks, 'well, is there a way to just simplify this by letting each new project just be a PMC?' My writeup asks, 'OK, if you want that, what _might_ it look like?' --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
