Re: proposal: mentor re-boot
Hi - We could better spend our energy looking at podlings with Mentor problems and deciding which of three possible states fits the podling. - Failed - no community is trully involved and there is nothing an active mentor could do. Let's just admit it and retire the podling. - Needs Help - a mentor would really help. They need it and want it. We try to find one. - Going Fine - could be a TLP. We help them graduate. I think the IPMC is doing almost all of the above better. Everything except for Failed. I think that now we are blaming the mentor. Let's get over it. Not every podling will work. Thanks. Regards, Dave On Jan 8, 2015, at 11:12 AM, Alan D. Cabrera wrote: On Jan 8, 2015, at 10:12 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: I'm not seeing how this proposal fixes the problem either. However, I do like that this proposal doesn't move responsibility and I like that it adds some teeth to the IPMC (e.g. removal of inactive mentors and pausing of podlings with insufficient mentors - though I still dispute ticking a box is hardly an indication of an active mentor) The thinking is that a mentor is at least honest; a reasonable assumption. If they claim to have reviewed a release or board report then they can be trusted to have done so to the best of their abilities. The two mentor minimum rule addresses the possible unevenness in ernest mentors’ abilities. There is no silver bullet but this proposal covers a lot of the perennial problems that the Incubator seems run into without changing responsibilities; a nice incremental step. It also simplifies the roles that podlings need to grok. Finally, it adds more impetus for PPMCs to take ownership in their incubation. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: proposal: mentor re-boot
On Wednesday, January 7, 2015, Alan D. Cabrera l...@toolazydogs.com wrote: On Jan 7, 2015, at 10:46 AM, jan i j...@apache.org javascript:; wrote: On 7 January 2015 at 19:32, Alan D. Cabrera l...@toolazydogs.com javascript:; wrote: On Jan 7, 2015, at 10:13 AM, Branko Čibej br...@apache.org javascript:; wrote: On 07.01.2015 18:42, Alan D. Cabrera wrote: I’ve written up a more comprehensive proposal that would not only hold mentors accountable but also give them a fair bit of autonomous authority during releases. https://wiki.apache.org/incubator/MentorRebootProposal https://wiki.apache.org/incubator/MentorRebootProposal What we would gain is transparency and simplicity. There would be no false expectations. Podlings would know where they stand. Work would be equitably distributed. No more layers. No more additional roles and confusing/diluted responsibilities. No more shuffling. What you're proposing, then, is that we institute mentor licenses with requirements over and above those for ASF membership. In effect, you'd create an additional level of earned merit for mentors ... which is probably a good thing. I don’t think that I’m following. Mentors need to be members of the IPMC but that doesn’t mean they need to be ASF members. What I don't understand is this: where's the motivation for anyone to submit to this additional burden? There's a lot of stick in your proposal, but a woeful lack of carrot ... so, most likely not going to work for a bunch of volunteers. What extra burden? The proposal is not asking mentors to do anything more than what they shouldn’t already be doing. All the proposal does is hold the mentors accountable for their inactivity and to add more of an incentive for PPMCs to be proactive in their relationships w/ mentors; something that the PPMCs shouldn’t already be doing. The carrot for both podlings and mentors is that there is no second gauntlet of voting/review by the IPMC for releases. In general I like the proposal especially the carrot. But I do have a couple of concerns: An active mentor is removed from a podling if that mentor does not review/sign off on a release. An active mentor is removed from a podling if that mentor does not review/sign off on a board report. Can a mentor not take vacation ? I think this need to contain a clause, that if the mentor has adviced the PPMC about the absence this will not happen. Yes, they certainly can! All they need to do is notify the PPMC and IPMC that they are going to be inactive. :) well You say that , but the text does not state the same. Being put on hold means that no committers can be added, no PPMC members can be added, and no releases can be performed This would be a no go for me. If a podling has lost a mentor, but are actively seeking a new mentor, the IPMC must step in to accept a new committer, PPMC member or release. The IPMC has accepted the podling, so it is very unfair, to punish a podling, that does a active job to replace a mentor. If a mentor really goes MIA, should those things be taking place without mentor oversight? IMO, no. No, this is not punishment, this just makes the current state of affairs clear and explicit. Plus, the PPMC needs to take on a more active role in things; they are not teenagers in the back seat. of course they would! first of all it only takes 1 mentor to do that not 2, secondly - new committers is the responsibility of the PPMC not the mentor - PPMC is the responsibility of PPMC/IPMC not the mentor - Releases is the responsibility of PPMC/IPMC not the mentor according to our current documentation. I don't disagree with your proposal, I just want an escape clausal in case a podling run into problems caused by our eager to over administrate. rgds jan i I really like the clear ruleset, this would also remove the need for shepherds I assume. Yep, and champions go away too. You’ll notice I've added a few more rules so that we address the reverse of “fascination of the ASF brand” issue. That being the “fascination of a podling brand”. If a mentor wants to be on the red carpet on opening day, they need to have put some skin in the game. Soo many things get simpler. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org javascript:; For additional commands, e-mail: general-h...@incubator.apache.org javascript:; -- Sent from My iPad, sorry for any misspellings.
Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator
+1 Pam Pamela L. Dragosh PMTS Research One ATT Way 4D-170P Bedminster, NJ 07921 908-901-2120 - Office pdrag...@research.att.com On 1/5/15, 2:04 PM, Hal Lockhart hal.lockh...@oracle.com wrote: I added a comma and the word and to the Mentors section. The Mentors are: Emmanuel Lécharny, Colm O hEigeartaigh and Hadrian Zbarcea Do you see any other formatting errors? Hal -Original Message- From: Roman Shaposhnik [mailto:ro...@shaposhnik.org] Sent: Monday, January 05, 2015 1:24 PM To: general@incubator.apache.org Subject: Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator Hi! can you please fix the formatting issues? For example, I can't even tell the exact list of mentors you're proposing. Thanks, Roman. On Mon, Jan 5, 2015 at 10:15 AM, Hal Lockhart hal.lockh...@oracle.com wrote: I call a vote to accept OpenAz as a new Incubator project. The proposal can be found here: https://wiki.apache.org/incubator/OpenAZProposal and is included below in this email. Voting will remain open until at least January 20, 2015 23:00 ET. Hal Lockhart - - - Abstract OpenAz is a project to create tools and libraries to enable the development of Attribute-based Access Control (ABAC) Systems in a variety of languages. In general the work is at least consistent with or actually conformant to the OASIS XACML Standard. Proposal Generally the work falls into two categories: ready to use tools which implement standardized or well understood components of an ABAC system and design proposals and proof of concept code relating to less well understood or experimental aspects of the problem. Much of the work to date has revolved around defining interfaces enabling a PEP to request an access control decision from a PDP. The XACML standard defines an abstract request format in xml and protocol wire formats in xaml and json, but it does not specify programmatic interfaces in any language. The standard says that the use of XML (or JSON) is not required only the semantic equivalent. The first Interface, AzAPI is modeled closely on the XACML defined interface, expressed in Java. One of the goals was to support calls to both a PDP local to the same process and a PDP in a remote server. AzAPI includes the interface, reference code to handle things like the many supported datatypes in XACML and glue code to mate it to the open source Sun XACML implementation. Because of the dependence on Sun XACML (which is XACML 2.0) the interface was missing some XACML 3.0 features. More recently this was corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was done by the JPMC team to support calling a remote PDP. WSo2 is also pursuing this capability. A second, higher level interface, PEPAPI was also defined. PEPAPI is more intended for application developers with little knowledge of XACML. It allows Java objects which contain attribute information to be passed in. Conversion methods, called mappers extract information from the objects and present it in the format expected by XACML. Some implementers have chosen to implement PEPAPI directly against their PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface which closely matches the Java one. Examples of more speculative work include: proposals for registration and dispatch of Obligation and Advice handlers, a scheme called AMF to tell PIPs how to retrieve attributes and PIP code to implement it, discussion of PoC code to demonstrate the use of XACML policies to drive OAuth interations and a proposal to use XACML policies to express OAuth scope. ATT has recently contributed their extensive XACML framework to the project. The ATT framework represents the entire XACML 3.0 object set as a collection of Java interfaces and standard implementations of those interfaces. The ATT PDP engine is built on top of this framework and represents a complete implementation of a XACML 3.0 PDP, including all of the multi-decision profiles. In addition, the framework also contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and XACML JSON Profile v1.0 WD 14. The PEP API includes annotation functionality, allowing application developers to simply annotate a Java class to provide attributes for a request. The annotation support removes the need for application developers to learn much of the API. The ATT framework also includes interfaces and implementations to standardize development of PIP engines that are used by the ATT PDP implementation, and can be used by other implementations built on top of the ATT framework. The framework also includes interfaces and implementations for a PAP distributed cloud infrastructure of PDP nodes that includes support for policy distribution and pip configurations. This PAP
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?'
Re: proposal: mentor re-boot
On 08/01/15 16:48, Chip Childers wrote: On Wed, Jan 07, 2015 at 08:18:59PM -0800, Marvin Humphrey wrote: Retiring the role of Champion sounds like an idea whose time has come. We gave the Champion additional oversight responsibilities a while back -- but how many times since then has having that additional layer made a difference? My 2 cents: In my experience, the Champion is a useful concept for the purpose of having discussions with the incoming project's community *before* they become a podling. I've acted as a champion for one podling so far, as well as acted in this role for one community that ended up *not* wanting to incubate. I see this as a valuable activity (I don't care what it's called), because it's important that incoming projects understand what they are signing up for. As much as it's an investment for the ASF to accept podlings, it's an investment for the inbound communities to make the proposal. For the project that I acted as a Champion for, I considered that part of the work to be done when they became a podling. I also asked to be a mentor, and am doing so now... and being a mentor is a bit different from that initial introduction. In the end though, regardless of what we name things, podlings should have support from people here in the incubator from the time they start considering the move to the time they become a TLP. +1 The other minor aspect of champion can making sure getting bootstrap happens quickly. Other mentors may not immediately be active, or as well known to the podling. It is admin smoothing over the transition, not vital, but helpful. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: proposal: mentor re-boot
+1 All we care about is that the podling has an active mentor who knows when to ask for support and gets that support when they need it. Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Branko Čibej [mailto:br...@apache.org] Sent: Thursday, January 8, 2015 7:06 AM To: general@incubator.apache.org Subject: Re: proposal: mentor re-boot On 08.01.2015 15:32, Alan D. Cabrera wrote: The two mentor minimum is critical. I was going to make it three but reasoned that if two were active, they could do the job. Why? I've not yet seen a single argument that would explain why you need at least two active mentors. One active mentor at any given time is sufficient for all current requirements. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator
+1 On Thu, Jan 8, 2015 at 7:14 PM, DRAGOSH, PAMELA L (PAM) pdrag...@research.att.com wrote: +1 Pam Pamela L. Dragosh PMTS Research One ATT Way 4D-170P Bedminster, NJ 07921 908-901-2120 - Office pdrag...@research.att.com On 1/5/15, 2:04 PM, Hal Lockhart hal.lockh...@oracle.com wrote: I added a comma and the word and to the Mentors section. The Mentors are: Emmanuel Lécharny, Colm O hEigeartaigh and Hadrian Zbarcea Do you see any other formatting errors? Hal -Original Message- From: Roman Shaposhnik [mailto:ro...@shaposhnik.org] Sent: Monday, January 05, 2015 1:24 PM To: general@incubator.apache.org Subject: Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator Hi! can you please fix the formatting issues? For example, I can't even tell the exact list of mentors you're proposing. Thanks, Roman. On Mon, Jan 5, 2015 at 10:15 AM, Hal Lockhart hal.lockh...@oracle.com wrote: I call a vote to accept OpenAz as a new Incubator project. The proposal can be found here: https://wiki.apache.org/incubator/OpenAZProposal and is included below in this email. Voting will remain open until at least January 20, 2015 23:00 ET. Hal Lockhart - - - Abstract OpenAz is a project to create tools and libraries to enable the development of Attribute-based Access Control (ABAC) Systems in a variety of languages. In general the work is at least consistent with or actually conformant to the OASIS XACML Standard. Proposal Generally the work falls into two categories: ready to use tools which implement standardized or well understood components of an ABAC system and design proposals and proof of concept code relating to less well understood or experimental aspects of the problem. Much of the work to date has revolved around defining interfaces enabling a PEP to request an access control decision from a PDP. The XACML standard defines an abstract request format in xml and protocol wire formats in xaml and json, but it does not specify programmatic interfaces in any language. The standard says that the use of XML (or JSON) is not required only the semantic equivalent. The first Interface, AzAPI is modeled closely on the XACML defined interface, expressed in Java. One of the goals was to support calls to both a PDP local to the same process and a PDP in a remote server. AzAPI includes the interface, reference code to handle things like the many supported datatypes in XACML and glue code to mate it to the open source Sun XACML implementation. Because of the dependence on Sun XACML (which is XACML 2.0) the interface was missing some XACML 3.0 features. More recently this was corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was done by the JPMC team to support calling a remote PDP. WSo2 is also pursuing this capability. A second, higher level interface, PEPAPI was also defined. PEPAPI is more intended for application developers with little knowledge of XACML. It allows Java objects which contain attribute information to be passed in. Conversion methods, called mappers extract information from the objects and present it in the format expected by XACML. Some implementers have chosen to implement PEPAPI directly against their PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface which closely matches the Java one. Examples of more speculative work include: proposals for registration and dispatch of Obligation and Advice handlers, a scheme called AMF to tell PIPs how to retrieve attributes and PIP code to implement it, discussion of PoC code to demonstrate the use of XACML policies to drive OAuth interations and a proposal to use XACML policies to express OAuth scope. ATT has recently contributed their extensive XACML framework to the project. The ATT framework represents the entire XACML 3.0 object set as a collection of Java interfaces and standard implementations of those interfaces. The ATT PDP engine is built on top of this framework and represents a complete implementation of a XACML 3.0 PDP, including all of the multi-decision profiles. In addition, the framework also contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and XACML JSON Profile v1.0 WD 14. The PEP API includes annotation functionality, allowing application developers to simply annotate a Java class to provide attributes for a request. The annotation support removes the need for application developers to learn much of the API. The ATT framework also includes interfaces and implementations to standardize development of PIP engines that are used by the ATT PDP implementation, and can be used by other implementations built on top of the ATT
Re: proposal: mentor re-boot
On Jan 8, 2015, at 10:06 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: +1 All we care about is that the podling has an active mentor who knows when to ask for support and gets that support when they need it. Following that statement to a logical conclusion, all podlings need to make a release is for one mentor to +1 it. That doesn’t match what we do today. How do you reconcile the minimum +1 voting requirement for releases we have to day with what you state above? Or are you guys saying that the podling can do everything but release w/ one active mentor, they need two to perform a release? Regards, Alan
RE: proposal: mentor re-boot
pTLP adds a great deal of overhead to the board unless there is a review process somewhere else. I've posted on this before so will not repeat here beyond summarizing as moving responsibility for the problem does not fix the problem. I'm not seeing how this proposal fixes the problem either. However, I do like that this proposal doesn't move responsibility and I like that it adds some teeth to the IPMC (e.g. removal of inactive mentors and pausing of podlings with insufficient mentors - though I still dispute ticking a box is hardly an indication of an active mentor) Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman Shaposhnik Sent: Thursday, January 8, 2015 8:09 AM To: general@incubator.apache.org Subject: Re: proposal: mentor re-boot On Thu, Jan 8, 2015 at 7:05 AM, Branko Čibej br...@apache.org wrote: On 08.01.2015 15:32, Alan D. Cabrera wrote: The two mentor minimum is critical. I was going to make it three but reasoned that if two were active, they could do the job. Why? I've not yet seen a single argument that would explain why you need at least two active mentors. One active mentor at any given time is sufficient for all current requirements. A very, very strong +1 to that. In fact, I'd say anything that adds to the complexity and bureaucracy of mentorship requirements -- is a 'no go' in my opinion. That's one reason I'm so strongly in favor of pTLP. They piggyback off of the process we already have adding very little bureaucracy and tracking overhead. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: proposal: mentor re-boot
Chip is correct. The tools we use in board meetings make it easy for us to see how many PMC members in a TLP resolution are members. If there are not enough we will sometimes put the project on an informal watch list (as well as ensuring appropriate people from the PMC go on the members watch list), occasionally we bounce the proposal back (this is pretty rare). With my Directors hat on I don't want a member being there just for mentoring, it confuses the evaluation since that person will appear as a committed PMC member but will in fact be nothing more than a mentor. What is important is that the PMC knows where to go for help when they are unsure of something. That expertise can (and should be) be present without a mentor or a Member on the PMC. Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Chip Childers [mailto:chipchild...@apache.org] Sent: Thursday, January 8, 2015 8:42 AM To: general@incubator.apache.org Subject: Re: proposal: mentor re-boot On Wed, Jan 07, 2015 at 05:20:40PM -0800, Henry Saputra wrote: +1 I would recommend to remove that particular line about mentor staying as mentor sake. Either mentors join in as full fledge PMC (and as committer) or not at all. +1, with the one comment that I've heard the board(s) review a list of initial PMC members to be sure that they believe there is enough experience within the PMC (typically by seeing if there are mentors and / or ASF members). IMO, this is likely a bit of a backstop in situations where a TLP would otherwise be an island. - Henry On Wed, Jan 7, 2015 at 4:56 PM, Branko Čibej br...@apache.org wrote: On 07.01.2015 22:45, Henry Saputra wrote: If a mentor asked to stay as PMC after graduation just for the sake of continue mentoring, then I would argue that the podling was not ready for graduation. A graduated TLP inviting the former mentor to the PMC is a different matter, but then the IPMC has neither mandate nor power to remove that person from the PMC. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On Mon, Jan 5, 2015 at 5:41 PM, Andrew Purtell apurt...@apache.org wrote: An addition of the overseeing committee, will shield the board from *some* of the day-to-day business of telling the pTLP that something needs to be fixed. Is this pretty close to IPMC in another name? No it isn't. First of all, the overseeing committee is NOT specific to incubation projects it can (and should!) be applied to all the project that board review reports for. Second of all, the comittee is a much more realistic extension of the board in that it, upfront, declares total absence of 'collective' responsibility. You don't approach the committee with the expectaions that it has collective responsibility to find volunteers that 'help projects'. The committee members have no other business but telling PMC of the pTLP (and hopefully TLPs at some point) that something is broken. That's it. This is very different from the charter that the IPMC has. Who gets to be on the new overseeing committee? Not current IPMC membership right? Correct. So is that a revocation of privilege in some respects? I don't think so. In a way, it is a promotion. All the *active* members (AKA mentors) get promoted to PMCs of pTLPs. A few IPMC members get promoted to the membership on the committee. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On Mon, Jan 5, 2015 at 5:49 PM, Andrew Purtell apurt...@apache.org wrote: One extra thing to note, that while we can *start* this comittee as dedicated to Incubating projects, it will be a very natural extension to get it involved in monitoring all of TLPs, not just pTLPs. What problem exists today where the Board needs such a buffer? Nobody says it does. At least not long term. If the board feels like they can handle the load themselves -- there's no need for the side of the committee that acts that way. However, it feels like a safer bet to try and have it first and then see if the load is light enough so that the board can act directly 100%. Btw, board *does* act directly even today (case in point the thread started by Rich). In what ways could this committee substitute its judgement for PMC of the TLP? Just as the board's job is to tell PMC when something's going wrong ditto with the committee. How would one apply to be on this committee? Would this be a case of some members being more member than others? I see it same way as ComDev (or any other ground like that). There's a voting process, you get nominated and accepted. The only qualification is that you *have* to be an ASF member. What would be the process and expectations for resolving disagreements between the TLP and this committee? Again, since the comittee is just acting as a 'clerk' for the board, the process is still the same as what we have today between the board and the TLPs. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: proposal: mentor re-boot
An ASF release needs three binding +1 votes (I see you say two but in your proposal but that would require a policy change in the ASF which I doubt will happen). If there is only a single mentor approaches the IPMC to ask for those votes. As a single active mentor on projects I have both asked the broader IPMC and sought out help from people privately who I trust to do the job well. Ross -Original Message- From: Alan D. Cabrera [mailto:l...@toolazydogs.com] Sent: Thursday, January 8, 2015 10:11 AM To: general@incubator.apache.org Subject: Re: proposal: mentor re-boot On Jan 8, 2015, at 10:06 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: +1 All we care about is that the podling has an active mentor who knows when to ask for support and gets that support when they need it. Following that statement to a logical conclusion, all podlings need to make a release is for one mentor to +1 it. That doesn’t match what we do today. How do you reconcile the minimum +1 voting requirement for releases we have to day with what you state above? Or are you guys saying that the podling can do everything but release w/ one active mentor, they need two to perform a release? Regards, Alan
Re: proposal: mentor re-boot
On Thu, Jan 8, 2015 at 1:16 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Chip is correct. The tools we use in board meetings make it easy for us to see how many PMC members in a TLP resolution are members. If there are not enough we will sometimes put the project on an informal watch list (as well as ensuring appropriate people from the PMC go on the members watch list), occasionally we bounce the proposal back (this is pretty rare). With my Directors hat on I don't want a member being there just for mentoring, it confuses the evaluation since that person will appear as a committed PMC member but will in fact be nothing more than a mentor. What is important is that the PMC knows where to go for help when they are unsure of something. That expertise can (and should be) be present without a mentor or a Member on the PMC. Maybe there's a hair to be split here. On a few occasions, I was asked by board members if I would join a graduating PMC that I had mentored. I have never felt that my role on these PMCs was to be a continuing mentor, it was to be a PMC member who had some extra experience, and I have been gradually leaving them over time.
Re: What is The Apache Way?
On 08.01.2015 05:30, Marvin Humphrey wrote: On Wed, Jan 7, 2015 at 12:54 PM, Alan D. Cabrera l...@toolazydogs.com wrote: Some podlings are graduating w/ no clear understanding of the Apache Way. What is The Apache Way? No one can say. There is no bounded set of expectations that an Apache project must fulfill. Where do Apache's official policies begin and end? Which best practices must be mastered? What will be enforced, what will be ignored? Every last podling graduates without a clear understanding of The Apache Way, because it is impossible to attain a clear understanding of The Apache Way. Dunno, I think the basics are pretty clear. * Contributors are individual volunteers (never representatives of employers). * Status is gained through merit (e.g., not through connections or tit-for-tat). * Decisions should be reached by consensus. * All project members are equal (e.g., PMC does not dictate to other committers) * Community is more important than code. Everything else (including requirements for releases) are minor technicalities and/or legal constraints. I find it horrifying that any ASF and especially IPMC member couldn't list these five basic points standing on their heads in a cold shower at 3 a.m. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: proposal: mentor re-boot
On Wed, Jan 07, 2015 at 08:18:59PM -0800, Marvin Humphrey wrote: Retiring the role of Champion sounds like an idea whose time has come. We gave the Champion additional oversight responsibilities a while back -- but how many times since then has having that additional layer made a difference? My 2 cents: In my experience, the Champion is a useful concept for the purpose of having discussions with the incoming project's community *before* they become a podling. I've acted as a champion for one podling so far, as well as acted in this role for one community that ended up *not* wanting to incubate. I see this as a valuable activity (I don't care what it's called), because it's important that incoming projects understand what they are signing up for. As much as it's an investment for the ASF to accept podlings, it's an investment for the inbound communities to make the proposal. For the project that I acted as a Champion for, I considered that part of the work to be done when they became a podling. I also asked to be a mentor, and am doing so now... and being a mentor is a bit different from that initial introduction. In the end though, regardless of what we name things, podlings should have support from people here in the incubator from the time they start considering the move to the time they become a TLP. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: proposal: mentor re-boot
On Wed, Jan 07, 2015 at 05:20:40PM -0800, Henry Saputra wrote: +1 I would recommend to remove that particular line about mentor staying as mentor sake. Either mentors join in as full fledge PMC (and as committer) or not at all. +1, with the one comment that I've heard the board(s) review a list of initial PMC members to be sure that they believe there is enough experience within the PMC (typically by seeing if there are mentors and / or ASF members). IMO, this is likely a bit of a backstop in situations where a TLP would otherwise be an island. - Henry On Wed, Jan 7, 2015 at 4:56 PM, Branko Čibej br...@apache.org wrote: On 07.01.2015 22:45, Henry Saputra wrote: If a mentor asked to stay as PMC after graduation just for the sake of continue mentoring, then I would argue that the podling was not ready for graduation. A graduated TLP inviting the former mentor to the PMC is a different matter, but then the IPMC has neither mandate nor power to remove that person from the PMC. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: What is The Apache Way?
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?) 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). Members should look to the board to enforce policy, not define it (Though Directors are members and will be involved with the definition) The Apache Way assumes that the best people to make decisions are the ones on the ground. We assume that nobody understands everything about a project and its community and we assume that people will not interfere where they don't have the expertise to do so. In the IPMC this means mentors will more often come to the IPMC for guidance, this is to be expected. The IPMC has committees to turn to for guidance (legal, marketing, brand, comdev etc.). In the majority if cases this works very well here in the IPMC. In some cases it does not. It is only the some cases we need be concerned about. Those cases are usually either projects with inadequate mentoring or bad mentoring. I don't want to accuse anyone if bad mentoring without evidence, so lets assume it is in attentiveness. Ross Sent from my Windows Phone From: Marvin Humphreymailto:mar...@rectangular.com Sent: 1/7/2015 8:32 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: What is The Apache Way? On Wed, Jan 7, 2015 at 12:54 PM, Alan D. Cabrera l...@toolazydogs.com wrote: Some podlings are graduating w/ no clear understanding of the Apache Way. What is The Apache Way? No one can say. There is no bounded set of expectations that an Apache project must fulfill. Where do Apache's official policies begin and end? Which best practices must be mastered? What will be enforced, what will be ignored? Every last podling graduates without a clear understanding of The Apache Way, because it is impossible to attain a clear understanding of The Apache Way. We can't fix that by restructuring the Incubator. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: proposal: mentor re-boot
On Thu, Jan 8, 2015 at 7:05 AM, Branko Čibej br...@apache.org wrote: On 08.01.2015 15:32, Alan D. Cabrera wrote: The two mentor minimum is critical. I was going to make it three but reasoned that if two were active, they could do the job. Why? I've not yet seen a single argument that would explain why you need at least two active mentors. One active mentor at any given time is sufficient for all current requirements. A very, very strong +1 to that. In fact, I'd say anything that adds to the complexity and bureaucracy of mentorship requirements -- is a 'no go' in my opinion. That's one reason I'm so strongly in favor of pTLP. They piggyback off of the process we already have adding very little bureaucracy and tracking overhead. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: proposal: mentor re-boot
Yes, Benson. You should take it as a compliment that if the board invite you to do remain and you agree then they trust you to be their eyes and ears, and if necessary the person they turn to in order to investigate a potentially issue. That's different from the mentor role in the IPMC though. Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Thursday, January 8, 2015 10:36 AM To: general@incubator.apache.org Subject: Re: proposal: mentor re-boot On Thu, Jan 8, 2015 at 1:16 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Chip is correct. The tools we use in board meetings make it easy for us to see how many PMC members in a TLP resolution are members. If there are not enough we will sometimes put the project on an informal watch list (as well as ensuring appropriate people from the PMC go on the members watch list), occasionally we bounce the proposal back (this is pretty rare). With my Directors hat on I don't want a member being there just for mentoring, it confuses the evaluation since that person will appear as a committed PMC member but will in fact be nothing more than a mentor. What is important is that the PMC knows where to go for help when they are unsure of something. That expertise can (and should be) be present without a mentor or a Member on the PMC. Maybe there's a hair to be split here. On a few occasions, I was asked by board members if I would join a graduating PMC that I had mentored. I have never felt that my role on these PMCs was to be a continuing mentor, it was to be a PMC member who had some extra experience, and I have been gradually leaving them over time. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: What is The Apache Way?
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
Re: What is The Apache Way?
On Thu, Jan 8, 2015 at 1:49 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: 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. Last for me for today: I recognize both of your debating styles, and my reference to Marvin was a combination of my personal tendency to conflict-aversion and an attempt, indeed, to distinguish between the narrow area where there can or should be rules, and the broader area where we are all discussing cultural diffusion without the use of initiation ceremonies. I particularly want to highlight my view that the most important thing is to know when you need help, and the other most important thing is for there to be help available.
Re: What is The Apache Way?
On 1/8/15, 10:49 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: 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. But what are the few immutable areas? Why isn’t there a link to a page that lists them instead of whole presentations to try to watch? I assume you don’t just mean “only source in official release”, “-1 vetoes a commit”, “3 +1 binding votes on releases”. -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? I'm reasonably sure that what he's looking for is not a rule book of how to run a consensus community IMO, Apache Flex spent a great deal of energy trying to reach consensus because we were told that “voting is a sign of failure”. Only recently did we find out (by having a former mentor return to help out) that consensus might only mean “general consensus” and not “consensus approval” as defined in the Apache Glossary. Some communities are blessed with people who get along well, but sometimes you can’t get everyone to agree and then you do have to know when it is time to vote and move on or not. Marvin may not need a rule book (or guide book) on consensus communities, but Flex sure could have used one. -Alex
Re: What is The Apache Way?
Members should look to the board to enforce policy, not define it (Though Directors are members and will be involved with the definition) This disagrees with much that the Foundation has published. In example: The membership of the ASF elects the 9 member board to run the foundation and to set and ensure policy. From: http://apache.org/foundation/ And whether I agree or disagree with your statement, this perfectly illustrates Marvin's point. Conflicting statements, that podlings see on websites, and then here from mentors, IPMC members, or even officers and directors make this incredibly convoluted for people who don't 'understand' the Apache Way, and more importantly, it's effect on a project community. And this happens all of the time. I recently was involved in an email conversation with a project that's considering coming to the Incubator. Involved in the conversation were 4 members, 3 of whom are officers, 1 of whom is a director, and we provided conflicting advice as to what was 'required' of a project at the ASF on specific points like bug trackers, mailing lists, etc. The reaction by folks from that project seemed to be one of wonder, curious which one of us was right?, Worried about the seeming inconsistency. I think that most of the projects that come into the Incubator, want to do the 'right thing'; we make that much more difficult by having such a variable answer to 'the right thing'. --David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: What is The Apache Way?
Years ago I started creating a signpost site over on http://community.apache.org which was intended provide a simplified gateway to our copious documents that describe the Apache Way in all its glory. Since then a few people have contributed to it. Our goal is to keep it simple, leave the details elsewhere but have the headlines on that site. We've been mostly successful in this. Unfortunately it is probably one of our best kept secrets. On this site you will find things like: http://community.apache.org/projectIndependence.html this document starts with While not all aspects of the Apache Way are practiced the same way by all projects at the ASF, there are a number of rules and policies that Apache projects are required to follow – things like complying with PMC release voting, legal policy, brand policy, using mailing lists, etc., which are documented in various places. (note the second sentence has 5 links, the rest of the document has some explanatory text and copious links). •Open Innovation in The Apache Software Foundation •Writing and Distributing Software The Apache Way •The Apache Software Foundation: No Jerks Allowed! •Putting It Together •An Overview of The Apache Software Foundation •Community Development at the ASF •The Apache Way and OpenOffice.org •Communities and Collaboration •Open Source Collaboration Tools are good for you •Life in Open Source Communities •Open Source enables Open Innovation •About: Apache - The Foundation, The Way, The Projects •Managing Community Open Source Brands There is *loads* of stuff over there. Ross -Original Message- From: Alex Harui [mailto:aha...@adobe.com] Sent: Thursday, January 8, 2015 11:19 AM To: general@incubator.apache.org Subject: Re: What is The Apache Way? On 1/8/15, 10:49 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: 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. But what are the few immutable areas? Why isn’t there a link to a page that lists them instead of whole presentations to try to watch? I assume you don’t just mean “only source in official release”, “-1 vetoes a commit”, “3 +1 binding votes on releases”. -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? I'm reasonably sure that what he's looking for is not a rule book of how to run a consensus community IMO, Apache Flex spent a great deal of energy trying to reach consensus because we were told that “voting is a sign of failure”. Only recently did we find out (by having a former mentor return to help out) that consensus might only mean “general consensus” and not “consensus approval” as defined in the Apache Glossary. Some communities are blessed with people who get along well, but sometimes you can’t get everyone to agree and then you do have to know when it is time to vote and move on or not. Marvin may not need a rule book (or guide book) on consensus communities, but Flex sure could have used one. -Alex B CB [ X ܚX KK[XZ[ [ \ [ ][ X ܚX P[ X ]܋ \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ [ \ [ Z[ [ X ]܋ \X K ܙ B
[jira] [Created] (INCUBATOR-128) Wrong email address in sample PPMC invitation email
Julian Hyde created INCUBATOR-128: - Summary: Wrong email address in sample PPMC invitation email Key: INCUBATOR-128 URL: https://issues.apache.org/jira/browse/INCUBATOR-128 Project: Incubator Issue Type: Bug Reporter: Julian Hyde The sample invitation email http://incubator.apache.org/guides/ppmc-offer.txt is very useful (thank you!). But the sample email address should be private-subscr...@frizzle.incubator.apache.org and not frizzle-private-subscr...@incubator.apache.org since that is the style for mailing lists these days. It's a minor point, but it wasted a couple of hours of a few people's time. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: What is The Apache Way?
It's process vs. culture. We shouldn't get hung up on process. Our bylaws (as a foundation) dictate that the board set the formal policies. This is pretty much a requirement of the way we have to be structured to get 501c(3) status. Someone needs to be accountable. So, yes, the board votes on policy and enforces it. However, the policies that are voted on are defined by the community as a whole. It is the boards job to find the appropriate policy that best matches the needs of the community. In most cases the board delegate this responsibility to some other committee. Where it is an operational concern it is delegated to a presidents committee, where it is a community concern to a board committee. Those committees invite the broader community to contribute to the discussion and make recommendations to the board which eventually become policy which is formally set and ensured by the board. The board are empowered and expected to ensure policies fit within the boundaries of our 501c(3) status and the foundations sustainability. They are also required to ensure that a policy that some sub-set of the foundation community requests is not in conflict with what another sub-set needs. So sometimes the board says no to a policy change, however, if the membership feel that the board is in error they are empowered to get rid of them. That being said, I do not disagree with you about conflicting opinions. That is an unfortunate side effect of looking to the those at the cliff face to make decisions. Everyone is looking at a different part of that cliff face and see different ways to climb. As Benson observes it is hard for us, as individuals, to know when we need to seek guidance. The foundation does provide mechanisms for getting a canonical answer - ask the relevant VP, if they are unsure they will consult the board. If the board are unsure they will consult the membership. Ross -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Thursday, January 8, 2015 11:45 AM To: general@incubator.apache.org Subject: Re: What is The Apache Way? Members should look to the board to enforce policy, not define it (Though Directors are members and will be involved with the definition) This disagrees with much that the Foundation has published. In example: The membership of the ASF elects the 9 member board to run the foundation and to set and ensure policy. From: http://apache.org/foundation/ And whether I agree or disagree with your statement, this perfectly illustrates Marvin's point. Conflicting statements, that podlings see on websites, and then here from mentors, IPMC members, or even officers and directors make this incredibly convoluted for people who don't 'understand' the Apache Way, and more importantly, it's effect on a project community. And this happens all of the time. I recently was involved in an email conversation with a project that's considering coming to the Incubator. Involved in the conversation were 4 members, 3 of whom are officers, 1 of whom is a director, and we provided conflicting advice as to what was 'required' of a project at the ASF on specific points like bug trackers, mailing lists, etc. The reaction by folks from that project seemed to be one of wonder, curious which one of us was right?, Worried about the seeming inconsistency. I think that most of the projects that come into the Incubator, want to do the 'right thing'; we make that much more difficult by having such a variable answer to 'the right thing'. --David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: What is The Apache Way?
Sorry I seem to have deleted a para from the below when editing for send. The para was also on this site you will find http://community.apache.org/speakers/slides.html which has decks from different people with titles like): •Open Innovation in The Apache Software Foundation •Writing and Distributing Software The Apache Way •The Apache Software Foundation: No Jerks Allowed! •Putting It Together •An Overview of The Apache Software Foundation •Community Development at the ASF •The Apache Way and OpenOffice.org •Communities and Collaboration •Open Source Collaboration Tools are good for you •Life in Open Source Communities •Open Source enables Open Innovation •About: Apache - The Foundation, The Way, The Projects •Managing Community Open Source Brands Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Ross Gardler (MS OPEN TECH) [mailto:ross.gard...@microsoft.com] Sent: Thursday, January 8, 2015 11:55 AM To: general@incubator.apache.org Subject: RE: What is The Apache Way? Years ago I started creating a signpost site over on http://community.apache.org which was intended provide a simplified gateway to our copious documents that describe the Apache Way in all its glory. Since then a few people have contributed to it. Our goal is to keep it simple, leave the details elsewhere but have the headlines on that site. We've been mostly successful in this. Unfortunately it is probably one of our best kept secrets. On this site you will find things like: http://community.apache.org/projectIndependence.html this document starts with While not all aspects of the Apache Way are practiced the same way by all projects at the ASF, there are a number of rules and policies that Apache projects are required to follow – things like complying with PMC release voting, legal policy, brand policy, using mailing lists, etc., which are documented in various places. (note the second sentence has 5 links, the rest of the document has some explanatory text and copious links). •Open Innovation in The Apache Software Foundation •Writing and Distributing Software The Apache Way •The Apache Software Foundation: No Jerks Allowed! •Putting It Together •An Overview of The Apache Software Foundation •Community Development at the ASF •The Apache Way and OpenOffice.org •Communities and Collaboration •Open Source Collaboration Tools are good for you •Life in Open Source Communities •Open Source enables Open Innovation •About: Apache - The Foundation, The Way, The Projects •Managing Community Open Source Brands There is *loads* of stuff over there. Ross -Original Message- From: Alex Harui [mailto:aha...@adobe.com] Sent: Thursday, January 8, 2015 11:19 AM To: general@incubator.apache.org Subject: Re: What is The Apache Way? On 1/8/15, 10:49 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: 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. But what are the few immutable areas? Why isn’t there a link to a page that lists them instead of whole presentations to try to watch? I assume you don’t just mean “only source in official release”, “-1 vetoes a commit”, “3 +1 binding votes on releases”. -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? I'm reasonably sure that what he's looking for is not a rule book of how to run a consensus community IMO, Apache Flex spent a great deal of energy trying to reach consensus because we were told that “voting is a sign of failure”. Only recently did we find out (by having a former mentor return to help out) that consensus might only mean “general consensus” and not “consensus approval” as defined in the Apache Glossary. Some communities are blessed with people who get along well, but sometimes you can’t get everyone to agree and then you do have to know when it is time to vote and move on or not. Marvin may not need a rule book (or guide book) on consensus communities, but Flex sure could have used one. -Alex B CB [ X ܚX KK[XZ[ [ \ [ ][ X ܚX P[ X ]܋ \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ [ \ [ Z[ [ X ]܋ \X K ܙ B B CB [ X ܚX KK[XZ[ [ \ [ ][ X ܚX P[ X ]܋ \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ [ \ [ Z[ [ X ]܋ \X K ܙ B - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
