Re: Clear expectations
On Tue, Jan 13, 2015 at 1:36 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Can you please expand on I think the answer starts with the very skepticism of top-down governance which has in large part kept us from having clear rules up till now. I'm not clear on what the skepticism is that you refer to as these threads have indicated that there are at least two very different views on whether there is, or is not, top down governance in the ASF. I meant to tip my hat to those who have spared Apache from adopting cumbersome absolute rules over the years. By skeptics, I was thinking of people who, when presented with an elaborate policy proposal, question whether some or all of it is truly required. It's clear that this undertaking calls for a governs best which governs least approach. We want the simplest rules possible; committing to concrete language is inherently constraining, and we want to minimize that effect. But just because Apache's requirements are underspecified right now doesn't mean we don't have any. Establishing where the rules begin and end will allow projects to spend less time researching and arguing over what is required. Projects may even discover newfound flexibility. For example, when the Incubator PMC clarified its collective understanding of release policy, it became able to reach consensus on approving many release candidates which would previously have been sent back. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Clear expectations
Well with that clarification I'm a very strong +1 on everything you said :-) Ross -Original Message- From: Marvin Humphrey [mailto:mar...@rectangular.com] Sent: Tuesday, January 13, 2015 6:49 PM To: general@incubator.apache.org Cc: Shane Curcuru Subject: Re: Clear expectations On Tue, Jan 13, 2015 at 1:36 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Can you please expand on I think the answer starts with the very skepticism of top-down governance which has in large part kept us from having clear rules up till now. I'm not clear on what the skepticism is that you refer to as these threads have indicated that there are at least two very different views on whether there is, or is not, top down governance in the ASF. I meant to tip my hat to those who have spared Apache from adopting cumbersome absolute rules over the years. By skeptics, I was thinking of people who, when presented with an elaborate policy proposal, question whether some or all of it is truly required. It's clear that this undertaking calls for a governs best which governs least approach. We want the simplest rules possible; committing to concrete language is inherently constraining, and we want to minimize that effect. But just because Apache's requirements are underspecified right now doesn't mean we don't have any. Establishing where the rules begin and end will allow projects to spend less time researching and arguing over what is required. Projects may even discover newfound flexibility. For example, when the Incubator PMC clarified its collective understanding of release policy, it became able to reach consensus on approving many release candidates which would previously have been sent back. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clear expectations
On Sun, Jan 11, 2015 at 7:18 PM, Benson Margulies bimargul...@gmail.com wrote: Does it help anything to look at this, again, as failure modes? How about this failure mode? A podling receives thorough instruction on some policy during incubation. After graduation, that policy gets violated, but most PMC members don't speak up because the rules are messy and poorly documented and they don't have enough confidence in their understanding to pursue the matter. Is that failure mode even related to the Incubator? Though you could argue that the passive PMC members did not learn to escalate, the main lesson I take from it is that unclear requirments are a problem for TLPs and the larger organization. The Incubator is teaching from an inadequate spec. That's a problem for us in that it wastes the time of Mentors and podlings. But the spec's inadequacy does not originate with the Incubator. The Incubator doesn't own that problem. The question I'd ask is, How can Apache create an awesome spec that's easy to teach, easy to learn, and easy to follow? I think the answer starts with the very skepticism of top-down governance which has in large part kept us from having clear rules up till now. That skepticism must be applied aggressively at every step of the way to ensure that we require no more than the bare minimum. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Clear expectations
Marvin, Can you please expand on I think the answer starts with the very skepticism of top-down governance which has in large part kept us from having clear rules up till now. I'm not clear on what the skepticism is that you refer to as these threads have indicated that there are at least two very different views on whether there is, or is not, top down governance in the ASF. Ross -Original Message- From: Marvin Humphrey [mailto:mar...@rectangular.com] Sent: Tuesday, January 13, 2015 1:27 PM To: general@incubator.apache.org; Shane Curcuru Subject: Re: Clear expectations On Sun, Jan 11, 2015 at 7:18 PM, Benson Margulies bimargul...@gmail.com wrote: Does it help anything to look at this, again, as failure modes? How about this failure mode? A podling receives thorough instruction on some policy during incubation. After graduation, that policy gets violated, but most PMC members don't speak up because the rules are messy and poorly documented and they don't have enough confidence in their understanding to pursue the matter. Is that failure mode even related to the Incubator? Though you could argue that the passive PMC members did not learn to escalate, the main lesson I take from it is that unclear requirments are a problem for TLPs and the larger organization. The Incubator is teaching from an inadequate spec. That's a problem for us in that it wastes the time of Mentors and podlings. But the spec's inadequacy does not originate with the Incubator. The Incubator doesn't own that problem. The question I'd ask is, How can Apache create an awesome spec that's easy to teach, easy to learn, and easy to follow? I think the answer starts with the very skepticism of top-down governance which has in large part kept us from having clear rules up till now. That skepticism must be applied aggressively at every step of the way to ensure that we require no more than the bare minimum. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clear expectations
On Sun, Jan 11, 2015 at 4:45 PM, Marvin Humphrey mar...@rectangular.com wrote: On Sat, Jan 10, 2015 at 12:41 PM, Jim Jagielski j...@jagunet.com wrote: Considering that both detailed answers as well and more philosophical answers don't satisfy, I am at a loss to what approach to try next. The Board should endorse a document establishing what Apache expects of its projects. This document must be as short as possible -- ideally no more than a single screenful. It should link to definitive resources rather than introduce competing language, and it should only codify existing requirements, not add new ones. Modification should require prior approval by a curating entity. The resources that this document will need to reference (release, legal voting, infra, security, etc) have varying levels of maturity. Separate efforts to codify satellite resources are important, since those often have amorphous boundaries themselves -- but that does not block the establishment of a root document. Shane Curcuru has submitted a first draft. It needs significant refinement, but I believe that it is conceptually sound. https://www.apache.org/dev/project-requirements Development discussions for this document should take place in a public forum -- probably dev@community. Eventual Board endorsement of this document as an authoritative resource is essential. That's what allows those who consult it to have confidence that they can know everything Apache requires without having to search through every last web page and email archive. Huge +1 (especially in the poddlings context) Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clear expectations
Does it help anything to look at this, again, as failure modes? One failure mode is a project that emerges from the incubator showing, well, gross signs that it 'doesn't get it.' Another failure mode is that a group of people who really do get it, at the level of the broad principles, get into trouble trying to translate those principles into very practical matters, due to conflicting sources of authority and documentation. Talking about one of these does not invalidate the other as a concern. I have an complementary suggestion to Marvin's push for documentation. My request is for a much clearer channel of communication to the board. All too often, projects wind up communicating with individuals; some board members, some not. Those individuals are in an unclear state of headware. Board members are always free to express their personal gut reaction, but I find that much confusion results from mistaking a gut reaction for an _ex cathedra_ statement -- and, in the end, board members don't even own such seats. Only the board together can issue a binding ruling. Since we're talking IPMC here, perhaps the solution is for the VP to even more actively take the role of 'bring your troubles to me, and I'll take them up with the board if I can't settle it.'
Re: Clear expectations
On Sun, Jan 11, 2015 at 7:18 PM, Benson Margulies bimargul...@gmail.com wrote: I have an complementary suggestion to Marvin's push for documentation. My request is for a much clearer channel of communication to the board. All too often, projects wind up communicating with individuals; some board members, some not. Those individuals are in an unclear state of headware. Board members are always free to express their personal gut reaction, but I find that much confusion results from mistaking a gut reaction for an _ex cathedra_ statement -- and, in the end, board members don't even own such seats. Only the board together can issue a binding ruling. Since we're talking IPMC here, perhaps the solution is for the VP to even more actively take the role of 'bring your troubles to me, and I'll take them up with the board if I can't settle it.' I've see that as the most frequent culprit: folks who are new to our game failing to tell apart opinions of the individuals and an opinion of the board. That's why I was so enthusiastically +1 on Marvin's suggestion of codifying at least the few commandments that the *board* can agree upon. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
