RE: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
For HTTPd I was referring to the assertion from Justin earlier in this thread FWIW, httpd always had nightly tarballs available for consumption and testing. (though reading that now I wonder if he meant source tarballs - which is an easy way of resolving this whole issue) Ross -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Wednesday, June 24, 2015 1:29 PM To: general@incubator.apache.org Subject: Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts On Wed, Jun 24, 2015 at 12:01 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: +1 (to this and Jochen's response) Roman was explicit in his question about clearly identifiable non-release artifacts available to the general public. We can debate words on a page forever, or we can work with the intent and get on with producing software. There is plenty of precedent here (including the oldest project in the foundation). Link please? because I can't find it, and a couple of folks from the httpd PMC tell me this isn't the case. I don't think there's a problem with snapshots or nightly builds being available. I do think there is a problem with promoting nightly builds, or even promoting them from the website. I do think that the Release Policy is binding on projects, and more so on podlings that haven't kicked out a release yet. More generally to the underlying issue that prompted this discussion: With the concrete example of Geode's DockerHub presence, I don't think it's acceptable: https://registry.hub.docker.com/u/apachegeode/geode/ Specifically, it's promoting folks consume a nightly build. There's no warning that this hasn't met the ASF standards for software, or that this project hasn't even pushed out a release yet. Then there's the fact that the dockerfile isn't even coming from the ASF it's coming from: https://github.com/markito/geode-docker --David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
+1 (to this and Jochen's response) Roman was explicit in his question about clearly identifiable non-release artifacts available to the general public. We can debate words on a page forever, or we can work with the intent and get on with producing software. There is plenty of precedent here (including the oldest project in the foundation). My summary of the intent: Don't advertise automated non-release artifacts in such a way that people may accidentally stumble across them and believe them to be production releases. That's it. Ross Sent from my Windows Phone From: Emmanuel Lécharnymailto:elecha...@gmail.com Sent: 6/24/2015 7:38 AM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts Le 24/06/15 14:04, Marvin Humphrey a écrit : On Tue, Jun 23, 2015 at 3:20 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: There is nothing preventing clearly identifiable non-release artifacts available to the general public. The Releases Policy page forbids it explicitly: During the process of developing software and preparing a release, various packages are made available to the developer community for testing purposes. **Do not include any links on the project website that might encourage non-developers to download and use nightly builds, snapshots, release candidates, or any other similar package.** The only people who are supposed to know about such packages are the people following the dev list (or searching its archives) and thus aware of the conditions placed on the package. If you find that the general public are downloading such test packages, then remove them. Under no circumstances are unapproved builds a substitute for releases. If this policy seems inconvenient, then release more often. Proper release management is a key aspect of Apache software development. What differentiates the general public from developers is whether they are aware of the conditions placed on the artifacts and thus exercising informed consent. Those conditions are are not limited to instability of the codebase, but also whether the artifacts meet Apache's licensing and legal requirements for releases. IMO, 'public' here means : 'exposed on the project's web site'. Whatever is built, and pushed on temporary spaces that are not mentionned on the project's web site does not enter in this category. The release policy does not state this is forbidden to produce those non-release builds, nor to push it somewhere reachable to anyone, but forbid advertizing about it (announce@a.o, or a news on the project's web site). What is important here is the spirit, not the letter : we want to be sure that those who download those non-release packages *know* what they are doing and what they are exposing themselves to. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
People wanting to use snapshot releases can be expected to jump through hoops to install those snapshots. NuGet, like all package management solutions, is a convenience not a requirement. People can still manually download and install libraries manually. Putting snapshots in public repositories, in my opinion, crosses the boundary of clearly differentiating releases from non-releases. Ross -Original Message- From: Markus Weimer [mailto:mar...@weimo.de] Sent: Wednesday, June 24, 2015 10:03 AM To: general@incubator.apache.org Subject: Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts Personally I think the policy should be clarified such that nightly builds MUST only live on ASF infrastructure (whether that be the Nexus SNAPSHOTs repo, committer web space etc). As soon as you start putting them on external services like DockerHub then they are potentially widely visible to the general public. This is very tricky for projects outside the Java ecosystem. For .NET, NuGet is the established way to get packages, and the ASF doesn't provide a NuGet repository in the same way it does provide Maven repositories. NuGet is just one example, each of the major language ecosystems now offers at least one (binary) artifact and dependency management approach. Following through on the above would mean either an incredible workload for the ASF to support it all, the exclusion of whole languages from ASF projects or treating some as second class citizens because their nightly builds wouldn't be testable. Neither of those strike me as great results. Markus - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts
There is nothing preventing clearly identifiable non-release artifacts available to the general public. Many projects make automated nightly builds available for example. Sent from my Windows Phone From: Roman Shaposhnikmailto:ro...@shaposhnik.org Sent: 6/23/2015 12:23 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts On Mon, Jun 22, 2015 at 10:16 PM, Marvin Humphrey mar...@rectangular.com wrote: The distinction is between people who develop the Apache product, and those who use the Apache product. Well, that's part of the reason behind me starting this thread: I think it is time for us to explicitly acknowledge a third role: an downstream project developer integrating with Apache *project*. I believe we have enough evidence that this group of people has unique requirements. How am I supposed to invite all the downstream developers of the world to start integrating with my awesome feature FOO before it gets formally released when our policy makes statement like: If the general public is being instructed to download a package, then that package has been released. Rather than invite them in before you make a release, why not release first and then invite them in? Because I want their feedback during the release cycle, not after. IOW, I need them to download and integrate with half-baked functionality that I may be not comfortable putting into a release. Are we really suggesting that I can not present at conference, tweet and otherwise promote the awesomeness of my project based on 'what's coming'? Why not release before presenting, tweeting, or promoting? See above. After all, we have a really good way of communicating that type of intent when it comes to branding: if you want to communicate that Apache FOO is a poddling you MUST refer to it as Apache FOO (incubating). Simple and effective. Exact opposite of our release policy that seems to completely discount labeling for communicating intent. I'm sorry, but a -SNAPSHOT labeling of a version ID communicates as much (if not more) to me as a writing on a website does. Lets just recognize that. If artifacts are being consumed by people other than those who develop the Apache product, those artifacts need to be vetted and voted. Like I said -- I'm 100% with you when it come to source artifacts. Can somebody please explain to me what is a the danger to the foundation is a [P]PMC wants to make a clearly identifiable non-release artifacts available to the general public? Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Blog policy for poddlings
It's not ComDev is press@ Sent from my Windows Phone From: Roman Shaposhnikmailto:ro...@shaposhnik.org Sent: 5/29/2015 7:11 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Blog policy for poddlings This is all very much confusing ;-) Is there any chance we can arrive at a more consistent policy or should I ask over at comdev@ ? Thanks, Roman. On Fri, May 29, 2015 at 11:46 AM, Henry Saputra henry.sapu...@gmail.com wrote: When Apache MetaModel still in incubator we were asking access to post blog at blogs.a.o and was told that it is preferable that podlings wait until graduation to post in it. - Henry On Fri, May 29, 2015 at 9:17 AM, David Nalley da...@gnsa.us wrote: I am unaware of a policy that would prohibit a podling from having a blog at blogs.a.o --David On Thu, May 28, 2015 at 9:36 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: Hi! can someone please remind me what's the policy for letting poddlings use blogs.apache.org as a blogging platform? Thanks, Roman. - 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: You know what... Apache is just too complicated.
+1000 Sent from my Windows Phone From: Bertrand Delacretazmailto:bdelacre...@apache.org Sent: 5/19/2015 5:18 AM To: Incubator Generalmailto:general@incubator.apache.org Subject: Re: You know what... Apache is just too complicated. Hi Stefan, On Mon, May 18, 2015 at 8:35 PM, Stefan Reich stefan.reich.maker.of@googlemail.com wrote: ...All you'd have to do is connect programmers to projects. Simple. Why all the rules?.. Out of curiosity, where did you find so many rules? The http://incubator.apache.org/ are way too verbose in my opinion, and often mix best practices with policy so I can understand that those can give such an impression. Does reading our project maturity model [1] leave you with the same too many rules impression? -Bertrand [1] https://community.apache.org/apache-way/apache-project-maturity-model.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [DISCUSS] Whimsy PMC
Not sure if your concern is diversity or scale, so I'll address both separately. If your concern is something else please be more explicit. Graduation does not require diversity of the PMC. It requires that the project be run according to the Apache Way which includes being open to any viewpoint brought to the project, regardless of the source. Furthermore, the initial set of committers covers a wide range of contributing orgs (although we are all doing this with ASF hats). Graduation does not require scale. Apache TLPs must be able to make a release. This boils down to at least three active PMC members. As for going straight to TLP I agree. Sam did say this was a possibility but I believe he (rightly so) wants to ensure that the proposal is solid before asking the board and IPMC to consider this path. Ross -Original Message- From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman Shaposhnik Sent: Tuesday, April 28, 2015 8:28 AM To: general@incubator.apache.org Subject: Re: [DISCUSS] Whimsy PMC Apologies if this has been asked, but Rich's points got me thinking. As it stands, I'm not sure I can see how Whimsy can graduate without us squinting just so. Basically, I don't see a clear way for the community to grow much beyond the initial list of committers. In a way, I'd rather see Whimsy got straight to TLP. I honestly see no point for it to go through the Incubator motions. Thoughts? Thanks, Roman. On Thu, Apr 23, 2015 at 11:46 AM, Sam Ruby ru...@intertwingly.net wrote: Initial sketch placed on the wiki: https://wiki.apache.org/incubator/WhimsyProposal Anyone who is so inclined is welcome to edit the proposal directly. No urgency or timeframe in mind (other than preferably starting sometime in 2015ish). My current thinking is to follow in Steve's footprints and go directly to TLP, but I'm starting a discussion here (in Incubator) to see if there are any other thoughts on the matter. - Sam Ruby - 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: [DISCUSS] Whimsy PMC
Sam, I don't *want* the role, but if you want one less task to do each month I'd be happy to take on the chair role. If someone actually *wants* the role then let them take it. Ross -Original Message- From: sa3r...@gmail.com [mailto:sa3r...@gmail.com] On Behalf Of Sam Ruby Sent: Tuesday, April 28, 2015 10:04 AM To: general@incubator.apache.org Subject: Re: [DISCUSS] Whimsy PMC On Tue, Apr 28, 2015 at 12:08 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: As for going straight to TLP I agree. Sam did say this was a possibility but I believe he (rightly so) wants to ensure that the proposal is solid before asking the board and IPMC to consider this path. Suffice it to say that the response has exceeded my expectations. My plans now are to add a resolution to the May agenda unless somebody identifies a problem that needs to be addressed. Meanwhile, two items that need attention: 1) podling name search. I've opened https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-75. I don't see a problem. If others do, please speak up. 2) naming of a chair. If anybody wants that position, please speak up. If nobody does, I'll put my name down. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [DISCUSS] Whimsy PMC
I've often wondered why we don't open source more of the infra code. Maybe this is the reason. Perhaps we need a new brand for such projects. Something like Apache Foo (Infra). This would be similar to the (Incubator) branding. We could even adopt some of the same policies (e.g. no press releases). If we find third parties start using and contributing to such code we can drop the (Infra) part. I'm really not sure this is necessary (see my earlier response), but since come folks have a concern I thought I'd throw it out there. If it makes you, David, as VP Infra more comfortable making infra produced code available then we should probably do it. Ross -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Tuesday, April 28, 2015 10:55 AM To: general@incubator.apache.org Subject: Re: [DISCUSS] Whimsy PMC On Mon, Apr 27, 2015 at 10:18 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: I’ll note that the only person I see from infra that has been proposed in the current PMC is Jake Ferrel: * Acquia: Jake Farrell Someone also correct me in that I don’t think Jake is a paid infra contractor. In addition the way I see this is that it is no different e.g., than contributing upstream to FreeBSD or whatever - Infra contractors may fix something and decide it’s in the ASF’s best interests to contribute it upstream - same may happen for Whimsy. But to date, ASF infra folk that are contractors I believe are not proposed to be directly paid to contribute to Whimsy. Should they do so, great. But in the famous words of Sam Ruby let’s deal with this if there is an actual data point instead of hypotheticals. I apologize for the double post. Yes, infra frequently submits patches to upstream projects. We also maintain our own set of patches for software that we use. And we write a decent amount of software. gitpubsub, all of the github integration, CMS, etc. Earlier this year, I was looking at what needed to be prioritized from an allocation of people. I spoke about a number of things with Ross and Rich, commented about conversations I had had earlier in 2014 about Whimsy. The timesaving and workflow benefits to exec officers and board members was emphasized. To be perfectly explicit - since mid-January - Dan Norris, a paid infra contractor, has been focused on Whimsy, the secretary workbench, etc. Some of that time has been understanding how things work today, defining a plan on making Whimsy better supported, improving monitoring ability, getting us closer aligned to how we want software to be deployed, and dealing with feature requests. And here is where my conflict comes in. With my VP Infra hat on, assuming there are no objections, my plan is to continue to task Dan Norris with that work. Whimsy is important to the operation of the foundation; and people come to infra when it isn't working. As long as those two remain true, Whimsy will remain something that I allocate folks time to, and in the case of Dan, I plan on allocating the bulk of his time there. With my ASF member/Board member hat on, I see this as the Foundation deciding that a project is important to the Foundation; and despite the fact that 'we don't pay for development' and that 'we pick runners not winners', we've effectively decided that this TLP is worth expending money on development for. That does worry me from a precedent standpoint. Is there a difference in us allocating developer time to a TLP as opposed to a codebase in the private infra svn tree? There are some; whether they matter or not remains a question. We don't release internal software. We don't brand it as Apache $foo. If this path is good for whimsy, it might be good for other projects infra has as well that are primarily written (now) by infra contractors. Gitpubsub, svngit2jira, etc. but could be used more widely. --David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [DISCUSS] Whimsy PMC
It's a tough one. We could be setting a precedence here that we absolutely do not want to set. On the other hand, it's problematic (not to mention simply ridiculous) if the foundation not being able to use Apache software because we don't pay for development and might want to submit a patch upstream. As long as all committers are equal and earn their merit in the traditional way I don't see a problem from the projects side. IN this instance the ASF is just another contributor to the project. This means the foundation never pays for development to something like the foundation never pays for development except where the modification is made as part of our normal infrastructure operations. On these rare occasions the foundation is just another employer and the contributor is just another community member. Changes are contributed upstream through the normal contribution process. There is no special role for ASF infra contractors. Ross -Original Message- From: sa3r...@gmail.com [mailto:sa3r...@gmail.com] On Behalf Of Sam Ruby Sent: Monday, April 27, 2015 6:11 PM To: general@incubator.apache.org Subject: Re: [DISCUSS] Whimsy PMC On Mon, Apr 27, 2015 at 7:12 PM, Rich Bowen rbo...@rcbowen.com wrote: On 04/27/2015 02:45 PM, Upayavira wrote: On Mon, Apr 27, 2015, at 06:50 PM, David Nalley wrote: On Thu, Apr 23, 2015 at 2:46 PM, Sam Ruby ru...@intertwingly.net wrote: Initial sketch placed on the wiki: https://wiki.apache.org/incubator/WhimsyProposal Anyone who is so inclined is welcome to edit the proposal directly. No urgency or timeframe in mind (other than preferably starting sometime in 2015ish). My current thinking is to follow in Steve's footprints and go directly to TLP, but I'm starting a discussion here (in Incubator) to see if there are any other thoughts on the matter. - Sam Ruby So one question (and perhaps a selfish concern). Infrastructure has a significant interest in whimsy (the service and codebase). I suspect that the ASF is also likely (at least for now) the primary user. Infrastructure has spent some time and resources, and even has a contractor that is paid on working on Whimsy and the associated areas. My question (and selfish concern) is: We have generally accepted that the ASF doesn't pay for development on projects. What does that mean for the contractors? Are they effectively forbidden from doing development work on Whimsy? In particular, I have a ruby developer working as a contractor who I'd like to working on things like Whimsy, secretary workbench, etc. What a wonderful question!! My take: a contractor cannot be paid to work on Whimsy, that's fair and understandable. He is paid to work on ASF infrastructure. However, as a part of fulfilling those duties, if he needs to work on Whimsy, or to code up a patch on httpd, or whatever, so be it. As far as the *project* is concerned, he is a volunteer the same as everyone else. He's being paid to work on infrastructure, not on Whimsy. This feels like sophistry, and a dangerous first step. If we have a *full time* employee who is working primarily on a particular project, then it's not odd to claim that they are being paid to develop Apache code. That being the case, then the ASF is doing that thing that we have asserted, for all time, that we will never do. I'll assert that infrastructure team routinely writes code. Random example: http://s.apache.org/wPQ I'm uncomfortable that much of that is special snowflake code; and some of it has a sole author capable of maintenance. I don't have personal knowledge of examples, but I do believe that from time to time the Infrastructure team has contributed patches upstream to the products they depend on (for example, FreeBSD?). One thing that I saw during my stint as VP Fundraising is that projects and the Foundation really are distinct things. The Foundation can contract someone to work on a project that it needs in order to support the work of the Foundation. If that happens to be contributing to an ASF project, so be it. However, they are not gaining any special privilege, they are as it were paid by an external entity just like all other contributors to any other ASF project. In this case, though, it will be the ASF paying for a developer to work on an ASF project. I hope that we're not just taking a convenient position that will bite us later. I trust that Ross, you, and David will find the right balance. -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - Sam Ruby - 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:
RE: [DISCUSS] Whimsy PMC
+1, that's what I was trying to convey. -Original Message- From: Greg Stein [mailto:gst...@gmail.com] Sent: Monday, April 27, 2015 7:05 PM To: general@incubator.apache.org Subject: Re: [DISCUSS] Whimsy PMC On Mon, Apr 27, 2015 at 8:51 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: It's a tough one. We could be setting a precedence here that we absolutely do not want to set. On the other hand, it's problematic (not to mention simply ridiculous) if the foundation not being able to use Apache software because we don't pay for development and might want to submit a patch upstream. As long as all committers are equal and earn their merit in the traditional way I don't see a problem from the projects side. IN this instance the ASF is just another contributor to the project. This means the foundation never pays for development to something like the foundation never pays for development except where the modification is made as part of our normal infrastructure operations. On these rare occasions the foundation is just another employer and the contributor is just another community member. Changes are contributed upstream through the normal contribution process. There is no special role for ASF infra contractors. The ASF pays for Infra contractors. Their job/role is to maintain our systems. Sometimes their duty *may* be to contribute software to $Project (wherever that may be). That is *very* distinct from paying a person to contribute directly to $ASFProject. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [DISCUSS] Whimsy PMC
Infra already supports Whimsy so having a TLP is irrelevant in that respect (although on reason Sam is doing this is because infra expressed a concern about maintaining a service that only had Sam working on it). Ross -Original Message- From: jan i [mailto:j...@apache.org] Sent: Thursday, April 23, 2015 2:32 PM To: general@incubator.apache.org Subject: Re: [DISCUSS] Whimsy PMC On Thursday, April 23, 2015, Sam Ruby ru...@intertwingly.net wrote: Initial sketch placed on the wiki: https://wiki.apache.org/incubator/WhimsyProposal Anyone who is so inclined is welcome to edit the proposal directly. No urgency or timeframe in mind (other than preferably starting sometime in 2015ish). My current thinking is to follow in Steve's footprints and go directly to TLP, but I'm starting a discussion here (in Incubator) to see if there are any other thoughts on the matter. I like the proposal, it is very clear, I do miss one bit though. If this becomes a TLP project is infra then prepared to support keeping whimsy running 24/7, or do they have additional requirements on the project? maybe the response to the above could be worked into the proposal. rgds jan i - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Sent from My iPad, sorry for any misspellings.
RE: [DISCUSS] Geode Incubation proposal
I believe we evaluate the community, not the code. However, in this case I would like to look at the code to get a feel for whether I would be interested in contributing to the project. Ross -Original Message- From: William A Rowe Jr [mailto:wr...@rowe-clan.net] Sent: Monday, April 13, 2015 12:33 AM To: general@incubator.apache.org Subject: RE: [DISCUSS] Geode Incubation proposal Ross, do we evaluate source code at the incubation-entry level, or do we evaluate proposed development goals and development community propositions? I'm curious about your thoughts. Yours, Bill On Apr 13, 2015 12:16 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Pivotal are asking me to agree to an evaluation license which I cannot view before I sign up. So I have to review the privacy policy first. Pivotal's privacy policy goes a *long* way beyond the point I am comfortable with when getting open source software (or deciding whether I want to agree with an evaluation license I can't read). I guess your defense could be that it's not open source yet, that's fine, but you are asking me, as an IPMC Member, to make a judgement on the validity of the proposal but I can't evaluate the code since I can't access it or the license under which I am allowed to view it. Most importantly, the export and license obligations you mention are something that have to go away before we can accept the project (or more accurately before it can graduate). Since I can't evaluate the code or the license I have no way of evaluating whether this is possible. There is no mention of such an item under known risks or the crypotography section of the proposal so what's this export stuff about (assuming the license thing is the evaluation license)? Given the points above I do not see how I can evaluate this proposal in its current form. Ross -Original Message- From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman Shaposhnik Sent: Sunday, April 12, 2015 11:56 PM To: general@incubator.apache.org Subject: Re: [DISCUSS] Geode Incubation proposal Since I'm getting a few off-list questions, I just want to make one point clear: On Sun, Apr 12, 2015 at 8:53 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: I'd also like to be able to review the source referred to in the proposal without having to sign up to the Pivotal network - how can I do that? The issue here is export and license compliance. Unfortunately, singing up is the only way to go right now. Why is it problematic for you? The software currently is NOT under ALv2. It is available under the evaluation license. The whole point of the proposal is to make it available under ALv2 as an Incubating project. Our apologies for making folks click through the evaluation license. Thanks, Roman. - 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: [DISCUSS] Geode Incubation proposal
It's nothing to do with my browser. If I click the download link I get asked to join the Pivotal Network before I can download it. If I understand the response below correctly you misspoke when you said there were export issues. That in fact there is no related export restriction, it's actually about the licensing issue. If that's the case then the proposal is correct in not highlighting these issues - thanks for clarifying that. I replied to the third part in response to Bill's question. However, to be sure my point gets across. Now that you have confirmed there are in fact no export restrictions then I have no problem with the proposal. However, I'd still like to be able to evaluate the code and to do so I would need to know what I'm agreeing to under the evaluation license. -Original Message- From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman Shaposhnik Sent: Monday, April 13, 2015 12:38 AM To: general@incubator.apache.org Subject: Re: [DISCUSS] Geode Incubation proposal On Sun, Apr 12, 2015 at 10:15 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Pivotal are asking me to agree to an evaluation license which I cannot view before I sign up. So I have to review the privacy policy first. This must be a bug in your browser. What OS/Browser are you using? The text of the license is also available in a separate file under the name Evaluation License: https://network.pivotal.io/products/project-geode Most importantly, the export and license obligations you mention are something that have to go away before we can accept the project (or more accurately before it can graduate). Since I can't evaluate the code or the license I have no way of evaluating whether this is possible. There is no mention of such an item under known risks or the crypotography section of the proposal so what's this export stuff about (assuming the license thing is the evaluation license)? Sorry for not being more explicit: this is just how Pivotal distribution network works. And we have to use it in this particular case in order to guarantee that the evaluation license has been explicitly acknowledged (as opposed to just being there in a tarball). All these constraints has nothing to do with the source code itself. Given the points above I do not see how I can evaluate this proposal in its current form. I see that Bill has asked the question that I wanted to ask here, so I'll let you reply in that part of the thread. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [DISCUSS] Geode Incubation proposal
Where hand over the Geode name also means hand over the domain name and GitHub organizations that have rather confusingly been launched in the last few days. I'd also like to be able to review the source referred to in the proposal without having to sign up to the Pivotal network - how can I do that? Ross -Original Message- From: John D. Ament [mailto:johndam...@apache.org] Sent: Sunday, April 12, 2015 1:50 PM To: general@incubator.apache.org Subject: Re: [DISCUSS] Geode Incubation proposal Roman, Is this the same as Project Geode which seems to be clogging my twitter feed this afternoon? http://projectgeode.org/ If so, it looks like you already figured out the naming issue. Is whoever behind this going to hand over the geode name to ASF? John On Sun, Apr 12, 2015 at 2:47 PM Roman Shaposhnik r...@apache.org wrote: Hi! I would like to open up a discussion thread on the proposals for the core of Pivotal's GemFire to join ASF as an incubating project under the name Geode. The proposal wiki is available here: https://wiki.apache.org/incubator/GeodeProposal and the text of the proposal is attached to the bottom of this email as well. Given the timing of ApacheCON, we would love to chat with anybody interested in giving us feedback. That said, of course, the bulk of the discussion is expected to happen on this thread. Thanks for your time and consideration! Roman (Geode proposal champion and a nominated mentor). == Abstract == Geode is a data management platform that provides real-time, consistent access to data-intensive applications throughout widely distributed cloud architectures. Geode pools memory (along with CPU, network and optionally local disk) across multiple processes to manage application objects and behavior. It uses dynamic replication and data partitioning techniques for high availability, improved performance, scalability, and fault tolerance. Geode is both a distributed data container and an in-memory data management system providing reliable asynchronous event notifications and guaranteed message delivery. == Proposal == The goal of this proposal is to bring the core of Pivotal Software, Inc.’s (Pivotal) Pivotal GemFireⓇ codebase into the Apache Software Foundation (ASF) in order to build a vibrant, diverse and self-governed open source community around the technology. Pivotal will continue to market and sell Pivotal GemFire based on Geode. Geode and Pivotal GemFire will be managed separately. This proposal covers the Geode source code (mainly written in Java), Geode documentation and other materials currently available on GitHub. While Geode is our primary choice for a name of the project, in order to facilitate PODLINGNAMESEARCH we have come up with two alternatives: * Haptic * FIG == Background == GemFire is an extremely mature and robust product that can trace its legacy all the way back to one of the first Object Databases for Smalltalk: GemStone. The GemFire code base has been maintained by the same group of engineers as a closed source project. Because of that, even though the engineers behind GemFire are the de-facto knowledge leaders for distributed in-memory management, they have had little exposure to the open source governance process.The original company developing GemStone and GemFire was acquired by VMWare in 2010 and later spun off as part of Pivotal Software in 2013. Today GemFire is used by over 600 enterprise customers. An example deployment includes China National Railways that uses Pivotal GemFire to run railway ticketing for the entire country of China with a 10 node cluster that manages 2 gigabytes hot data in memory, and 10 backup nodes for high availability and elastic scale. == Rationale == Modern-day data management architectures require a robust in-memory data grid solution to handle a variety of use cases, ranging from enterprise-wide caching to real-time transactional applications at scale. In addition, as memory size and network bandwidth growth continues to outpace those of disk, the importance of managing large pools of RAM at scale increases. It is essential to innovate at the same pace and Pivotal strongly believes that in the Big Data space, this can be optimally achieved through a vibrant, diverse, self-governed community collectively innovating around a single codebase while at the same time cross-pollinating with various other data management communities. ASF is the ideal place to meet these ambitious goals. == Initial Goals == Our initial goals are to bring Geode into the ASF, transition internal engineering processes into the open, and foster a collaborative development model according to the Apache Way. Pivotal plans to develop new functionality in an open, community-driven way. To get there, the existing internal build, test and release processes will be refactored to support open
RE: [DISCUSS] Geode Incubation proposal
Pivotal are asking me to agree to an evaluation license which I cannot view before I sign up. So I have to review the privacy policy first. Pivotal's privacy policy goes a *long* way beyond the point I am comfortable with when getting open source software (or deciding whether I want to agree with an evaluation license I can't read). I guess your defense could be that it's not open source yet, that's fine, but you are asking me, as an IPMC Member, to make a judgement on the validity of the proposal but I can't evaluate the code since I can't access it or the license under which I am allowed to view it. Most importantly, the export and license obligations you mention are something that have to go away before we can accept the project (or more accurately before it can graduate). Since I can't evaluate the code or the license I have no way of evaluating whether this is possible. There is no mention of such an item under known risks or the crypotography section of the proposal so what's this export stuff about (assuming the license thing is the evaluation license)? Given the points above I do not see how I can evaluate this proposal in its current form. Ross -Original Message- From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman Shaposhnik Sent: Sunday, April 12, 2015 11:56 PM To: general@incubator.apache.org Subject: Re: [DISCUSS] Geode Incubation proposal Since I'm getting a few off-list questions, I just want to make one point clear: On Sun, Apr 12, 2015 at 8:53 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: I'd also like to be able to review the source referred to in the proposal without having to sign up to the Pivotal network - how can I do that? The issue here is export and license compliance. Unfortunately, singing up is the only way to go right now. Why is it problematic for you? The software currently is NOT under ALv2. It is available under the evaluation license. The whole point of the proposal is to make it available under ALv2 as an Incubating project. Our apologies for making folks click through the evaluation license. Thanks, Roman. - 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: [POLL] Using this list to discuss pTLP proposals, ok?
My only concern is confusion over pTLP and incubator. That's a manageable concern but this lost is so large I fear it might keep recurring. Just a word of caution, not an objection. Sent from my Windows Phone From: jan imailto:j...@apache.org Sent: 3/22/2015 9:04 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: [POLL] Using this list to discuss pTLP proposals, ok? On Sunday, March 22, 2015, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, In the recent discussions about provisional TLPs and direct-to-TLP projects we're missing a public place where the proposals (board resolutions etc) for such projects are discussed and worked on. Are people ok with using this list and the Incubator wiki for those things? +1 of course rgds jan i The Incubator PMC won't have a say in how those projects proceed, but as this is about creating new projects, and as a number of steps are similar to incoming or graduating podlings, I think working here makes sense. Thoughts? -Bertrand - 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: IP Clearance Questions
1. CCLA is never used instead of an SGA, they serve different purposes. The SGA is for a body of work that pre-exists entry into the foundation. The CCLA is an optional document that says future work by named individuals can be contributed. 2. Yes (although secretary tries his best to CC the appropriate people on his replies) 3. Yes 4. Pass - so I'll repeat the question for others - The incubator drop area [3] doesn't seem to exist. Where should I commit the tarball once everything else is in order? Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: P. Taylor Goetz [mailto:ptgo...@gmail.com] Sent: Monday, March 16, 2015 12:20 PM To: Incubator Subject: IP Clearance Questions I'm working on filling out the necessary IP Clearance paperwork for code donation and have a few questions (forgive me if they are stupid, this is my first time through the process): Based on the IP clearance template documentation [1]: 1. When should a CCLA be used as opposed to a grant [2]? 2. How do I verify that a grant or ccla has been acknowledged by the ASF Secretary? Poll the grants.txt/cclas.txt files for changes? 3. I assume I don't commit anything until the grant/ccla has been acknowledged. Is this correct? 4. The incubator drop area [3] doesn't seem to exist. Where should I commit the tarball once everything else is in order? Thanks in advance, -Taylor [1] http://incubator.apache.org/ip-clearance/ip-clearance-template.html [2] https://www.apache.org/licenses/software-grant.txt [3] https://svn.apache.org/repos/asf/incubator/donations - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Wave community may need our help
Don't worry Christian. Same thing for me last month, and someone else the month before. Signing the report is not a replacement for actually being involved. Sounds like you are doing a great job. Sent from my Windows Phone From: Christian Grobmeiermailto:grobme...@apache.org Sent: 3/12/2015 11:39 PM To: Roman Shaposhnikmailto:r...@apache.org; general@incubator.apache.orgmailto:general@incubator.apache.org Cc: Upayaviramailto:u...@odoko.co.uk Subject: Re: Wave community may need our help Hi Roman, you might have noticed, that one of the mentors (me) were actively asking for this report. I simply forgot to sign it, which does not happen often to me. In example, the last report was signed (Dec). More mentors are always welcome; but its not this podling is out on his own. From mentoring activities, I even joined a Google Hangout to clarify questions, and releases were reviewed. When it comes to the situation of this podling, it hasn't changed much. I wonder why you think Wave would turn the corner. From time to time I start the retirement discussion at the podling as I don't think Wave will get enough momentum. There is a small community, but they cannot dedicate enough time. My personal opinion is that it will not make graduation at any time, and i told that before. I am happy if the project turns out otherwise. That being said, I am still on mailing lists, i am still helping out, I just wasn't there in the past 10 days for personal reasons. Again, I wrote this response to help giving the right impression on the podling, not to put your good intentions down to help. I am really happy if somebody else would help as mentor, as well as with log4cxx and ripple. Thanks, Christian -- Christian Grobmeier grobme...@gmail.com On Fri, Mar 13, 2015, at 00:48, Roman Shaposhnik wrote: Hi! all throughout my tenure I was keeping an eye on Wave trying to figure out how we can help that community. The poddling has been incubating close to 5 years and for a long time they've struggled with the basics of producing the release and growing the community beyond its core. I was extremely excited to see that this reporting cycle they seem to be finally turning the corner. Unfortunately, next thing I saw was that the report wasn't signed off by mentors. I totally understand that we all get busy (hey -- I was supposed to submit the final report yesterday -- totally didn't happen). It is just that if the community is really on the verge of turning the corner I think it really behoves us to help them as much as we can. Thoughts on how we can revitalize mentoring around Wave? Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [DISCUSS] Groovy Incubation proposal
+1 See C030 on our project maturity model http://community.apache.org/apache-way/apache-project-maturity-model.html And some commentary on committer = someone who is committed rather than someone who commits code https://community.apache.org/contributors/ Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Ted Dunning [mailto:ted.dunn...@gmail.com] Sent: Thursday, March 12, 2015 9:22 AM To: general@incubator.apache.org Cc: Cédric Champeau; Paul King; pascalschumacher; Guillaume Laforge Subject: Re: [DISCUSS] Groovy Incubation proposal On Thu, Mar 12, 2015 at 4:04 AM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: * several writers of documentation (without committer privileges) * one or two creators of graphics (icons, or whatever, without committer privileges) * one or more organizations providing hosting services, and the like This is a good list. But I take strong issue with the without committer privileges part. If somebody is contributing, make them committers. Expect them to be responsible about what they commit and follow whatever process there is. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Soliciting feedback for a detailed pTLP policy document
Remember this is not a replacement for the IPMC, it is an alternative for appropriate projects. The problem you highlight is the one that concerns me most about this proposal. However, if we select pTLP candidates carefully there should be no problem. Also note that you are incorrect in saying you will never get a binding vote. Earn merit in the community and get yourself invited into the PMC and you have a binding vote. Ross Sent from my Windows Phone From: John D. Amentmailto:johndam...@apache.org Sent: 3/2/2015 7:33 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org; Bertrand Delacretazmailto:bdelacre...@apache.org; Sam Rubymailto:ru...@intertwingly.net Cc: Apache Boardmailto:bo...@apache.org Subject: Re: Soliciting feedback for a detailed pTLP policy document I obviously speak for the minority, but as a non-Apache Member I would never be able to provide a binding vote in a pTLP. We just had a case where the 4 IPMC representatives are made up of 1 current IPMC Member, 2 IPMC non-members and 1 Member pending IPMC. On Mon, Mar 2, 2015 at 10:05 PM Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.commailto:ross.gard...@microsoft.com wrote: How do you see yourself being limited in the support you can provide? Sent from my Windows Phone From: John D. Amentmailto:johndam...@apache.orgmailto:johndam...@apache.org Sent: 3/2/2015 6:56 PM To: general@incubator.apache.orgmailto:general@incubator.apache.orgmailto:general@incubator.apache.orgmailto:general@incubator.apache.org; Bertrand Delacretazmailto:bdelacre...@apache.orgmailto:bdelacre...@apache.org; Sam Rubymailto:ru...@intertwingly.netmailto:ru...@intertwingly.net Cc: Apache Boardmailto:bo...@apache.orgmailto:bo...@apache.org Subject: Re: Soliciting feedback for a detailed pTLP policy document Roman, I don't think much is missing. One of my concerns with all of these proposals, especially for participants like myself, is the difference in how the IPMC operates vs how these PMCs must operate. For someone like me, I wouldn't be able to help these pTLP's the way I can on the IPMC. From a document's standpoint, I'm concerned with heavy reliance on three existing Apache members. Specifically, if the pTLP gets into a situation where only 2 of its 3 members are active, they can't even add an additional member. While having three active participants is crucial (from the tone of the document), as soon as one of those three starts failing, they cannot ever recover without that 3rd person rejoining. This approach seems to favor cases where the pTLP is proposed and managed by an existing member. I can see this approach not helping foster external groups from joining the ASF, especially trying to find three members openly willing to help foster that community. I can think of a few members who have no interest in helping to mentor projects. So if the hope is to get these folks involved, I look forward to seeing the results. John On Mon, Mar 2, 2015 at 8:33 PM Roman Shaposhnik r...@apache.orgmailto:r...@apache.org wrote: Hi! since a few board members requested a detailed document outlining the exact policy of a pTLP project, I've created this: https://cwiki.apache.org/confluence/pages/viewpage. action?pageId=51812862 which is modeled after the Incubator policy document. My rationale is this: if the level of details of the Incubator policy is considered good enough for poddlings, holding pTLP project to higher level of standard would be unfair. At this point, I would like to open this document for soliciting as wide a feedback as possible. I would like to especially request attention of the ASF board members who asked for this type of a document to be available. Please feel free to either comment on this email thread or edit the document directly (do send me your Confluence IDs so I can give you karma, though). I would like to see if we can build consensus around this policy in time for the March board meeting so that Zest can try one more time to join ASF as a pTLP project. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.orgmailto:general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.orgmailto:general-h...@incubator.apache.org
RE: Soliciting feedback for a detailed pTLP policy document
How do you see yourself being limited in the support you can provide? Sent from my Windows Phone From: John D. Amentmailto:johndam...@apache.org Sent: 3/2/2015 6:56 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org; Bertrand Delacretazmailto:bdelacre...@apache.org; Sam Rubymailto:ru...@intertwingly.net Cc: Apache Boardmailto:bo...@apache.org Subject: Re: Soliciting feedback for a detailed pTLP policy document Roman, I don't think much is missing. One of my concerns with all of these proposals, especially for participants like myself, is the difference in how the IPMC operates vs how these PMCs must operate. For someone like me, I wouldn't be able to help these pTLP's the way I can on the IPMC. From a document's standpoint, I'm concerned with heavy reliance on three existing Apache members. Specifically, if the pTLP gets into a situation where only 2 of its 3 members are active, they can't even add an additional member. While having three active participants is crucial (from the tone of the document), as soon as one of those three starts failing, they cannot ever recover without that 3rd person rejoining. This approach seems to favor cases where the pTLP is proposed and managed by an existing member. I can see this approach not helping foster external groups from joining the ASF, especially trying to find three members openly willing to help foster that community. I can think of a few members who have no interest in helping to mentor projects. So if the hope is to get these folks involved, I look forward to seeing the results. John On Mon, Mar 2, 2015 at 8:33 PM Roman Shaposhnik r...@apache.org wrote: Hi! since a few board members requested a detailed document outlining the exact policy of a pTLP project, I've created this: https://cwiki.apache.org/confluence/pages/viewpage. action?pageId=51812862 which is modeled after the Incubator policy document. My rationale is this: if the level of details of the Incubator policy is considered good enough for poddlings, holding pTLP project to higher level of standard would be unfair. At this point, I would like to open this document for soliciting as wide a feedback as possible. I would like to especially request attention of the ASF board members who asked for this type of a document to be available. Please feel free to either comment on this email thread or edit the document directly (do send me your Confluence IDs so I can give you karma, though). I would like to see if we can build consensus around this policy in time for the March board meeting so that Zest can try one more time to join ASF as a pTLP project. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Soliciting feedback for a detailed pTLP policy document
Can you please remove the requirement for 3 legally independent PMC members. What we require is a PMC that operates as a meritocracy. This is possible even in a monoculture PMC. It's also possible to have the independent representatives that act in collusion. 3 independents was a useful yardstick in the original IPMC policies. Over the years it became a concrete requirement. We should go back to the original intent both in the IPMC and the pTLP proposal. Ross Sent from my Windows Phone From: Roman Shaposhnikmailto:r...@apache.org Sent: 3/2/2015 5:31 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org; Bertrand Delacretazmailto:bdelacre...@apache.org; Sam Rubymailto:ru...@intertwingly.net Cc: Apache Boardmailto:bo...@apache.org Subject: Soliciting feedback for a detailed pTLP policy document Hi! since a few board members requested a detailed document outlining the exact policy of a pTLP project, I've created this: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=51812862 which is modeled after the Incubator policy document. My rationale is this: if the level of details of the Incubator policy is considered good enough for poddlings, holding pTLP project to higher level of standard would be unfair. At this point, I would like to open this document for soliciting as wide a feedback as possible. I would like to especially request attention of the ASF board members who asked for this type of a document to be available. Please feel free to either comment on this email thread or edit the document directly (do send me your Confluence IDs so I can give you karma, though). I would like to see if we can build consensus around this policy in time for the March board meeting so that Zest can try one more time to join ASF as a pTLP project. Thanks, Roman.
RE: Soliciting feedback for a detailed pTLP policy document
If that were true then the project would not be operating as an Apache project which requires that all community members have a voice. Graduation requires the project be operating as an Apache project. In such a project there is a difference between a binding vote and a non-binding vote only in the legal aspects of the foundation. From a community perspective any valid opinion should be supported by those with binding vote. Sent from my Windows Phone From: John D. Amentmailto:johndam...@apache.org Sent: 3/2/2015 7:50 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Cc: Bertrand Delacretazmailto:bdelacre...@apache.org; Sam Rubymailto:ru...@intertwingly.net; bo...@apache.orgmailto:bo...@apache.org Subject: RE: Soliciting feedback for a detailed pTLP policy document I may be taking a more cynical interpretation, but when I see that three votes from members are required that means that all other votes don't matter. On Mar 2, 2015 10:45 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Remember this is not a replacement for the IPMC, it is an alternative for appropriate projects. The problem you highlight is the one that concerns me most about this proposal. However, if we select pTLP candidates carefully there should be no problem. Also note that you are incorrect in saying you will never get a binding vote. Earn merit in the community and get yourself invited into the PMC and you have a binding vote. Ross Sent from my Windows Phone From: John D. Amentmailto:johndam...@apache.org Sent: 3/2/2015 7:33 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org; Bertrand Delacretazmailto:bdelacre...@apache.org; Sam Rubymailto: ru...@intertwingly.net Cc: Apache Boardmailto:bo...@apache.org Subject: Re: Soliciting feedback for a detailed pTLP policy document I obviously speak for the minority, but as a non-Apache Member I would never be able to provide a binding vote in a pTLP. We just had a case where the 4 IPMC representatives are made up of 1 current IPMC Member, 2 IPMC non-members and 1 Member pending IPMC. On Mon, Mar 2, 2015 at 10:05 PM Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.commailto:ross.gard...@microsoft.com wrote: How do you see yourself being limited in the support you can provide? Sent from my Windows Phone From: John D. Amentmailto:johndam...@apache.orgmailto: johndam...@apache.org Sent: 3/2/2015 6:56 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org mailto:general@incubator.apache.orgmailto:general@incubator.apache.org; Bertrand Delacretazmailto:bdelacre...@apache.orgmailto: bdelacre...@apache.org; Sam Rubymailto:ru...@intertwingly.netmailto: ru...@intertwingly.net Cc: Apache Boardmailto:bo...@apache.orgmailto:bo...@apache.org Subject: Re: Soliciting feedback for a detailed pTLP policy document Roman, I don't think much is missing. One of my concerns with all of these proposals, especially for participants like myself, is the difference in how the IPMC operates vs how these PMCs must operate. For someone like me, I wouldn't be able to help these pTLP's the way I can on the IPMC. From a document's standpoint, I'm concerned with heavy reliance on three existing Apache members. Specifically, if the pTLP gets into a situation where only 2 of its 3 members are active, they can't even add an additional member. While having three active participants is crucial (from the tone of the document), as soon as one of those three starts failing, they cannot ever recover without that 3rd person rejoining. This approach seems to favor cases where the pTLP is proposed and managed by an existing member. I can see this approach not helping foster external groups from joining the ASF, especially trying to find three members openly willing to help foster that community. I can think of a few members who have no interest in helping to mentor projects. So if the hope is to get these folks involved, I look forward to seeing the results. John On Mon, Mar 2, 2015 at 8:33 PM Roman Shaposhnik r...@apache.orgmailto: r...@apache.org wrote: Hi! since a few board members requested a detailed document outlining the exact policy of a pTLP project, I've created this: https://cwiki.apache.org/confluence/pages/viewpage. action?pageId=51812862 which is modeled after the Incubator policy document. My rationale is this: if the level of details of the Incubator policy is considered good enough for poddlings, holding pTLP project to higher level of standard would be unfair. At this point, I would like to open this document for soliciting as wide a feedback as possible. I would like to especially request attention of the ASF board members who asked for this type of a document to be available. Please feel free to either comment
RE: pTLP process amendments
+1 either this pTLP idea is independent of the IPMC. Or it is not. We need to lose these mixed messages. It seems people are still using the same ten to represent different things. Sent from my Windows Phone From: Niclas Hedhmanmailto:nic...@hedhman.org Sent: 3/1/2015 6:38 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: pTLP process amendments Marvin, I think the IPMC doesn't need to do anything, and instead the dissolution of Incubator's duties are put into the Board Resolution, just as they are with the normal graduation resolution. So, from the Incubator's point of view, there is no effort, podling disappears and the pTLP is expected to clean up its Incubator presence just like a podling is expected to do once it graduates. // Niclas On Mon, Mar 2, 2015 at 3:29 AM, Marvin Humphrey mar...@rectangular.com wrote: On Thu, Feb 26, 2015 at 11:08 PM, Greg Stein gst...@gmail.com wrote: On Wed, Feb 25, 2015 at 7:08 AM, Marvin Humphrey mar...@rectangular.com wrote: On Wed, Feb 25, 2015 at 4:35 AM, Niclas Hedhman nic...@hedhman.org wrote: On Wed, Feb 25, 2015 at 8:27 PM, jan i j...@apache.org wrote: The proposal only refer to new projects entering Apache, would it be worth while to consider a way for projects that entered Incubator recently and has enough (whatever that is) asf members as committers ? That is a discussion for perhaps the Incubator, but more specifically the podlings that you might be referring to. I don't see why the Incubator wouldn't just let them go. Haha well, the reality is that the Incubator wouldn't have a choice. If the Board passes a pTLP resolution, then there isn't much the IPMC could do about it :-P Clearly the pTLP resolution is outside the Incubator's jurisdiction -- the only question is how the podling gets closed down. Presumably things would go something like this: 1. Podling community votes to endorse pTLP resolution. 2. Board passes pTLP resolution. 3. IPMC passes a pro forma vote to dissolve/retire/whatever the podling. Now, I'm not suggesting the Board would be eager to just rip podlings out of the Incubator with *some* modicum of discussion with the IPMC. I'm just pedantically pointing out the reality of the situation... hehe... I wouldn't expect the process to be contentious at all. Odds are that most or all of the Mentors for such a podling will have signed up as seed PMC members for the pTLP, and the podling community will already have arrived at consensus in favor of the pTLP process. Under such circumstances, it's inconceivable that the wider IPMC would stand in the way. Many of us are grateful to those of you who are running this experiment, even if we remain skeptical of the model. I'm happy that it's not being run under the auspices of the Incubator and I'm generally trying to stay out of the way. The only reason I commented was to reassure that this particular spot where the pTLP experiment interfaces with the Incubator won't be a source of friction. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java
RE: Practical next steps for pTLP experiment
Ok let me try again. I am in support of pTLP where it is clear it will work for a given project. Sam makes a good point that if we are sure it will work why bother. Just make it a TLP and be done with it. This version of orthogonal to the IPMC. I agree and I think its a great idea. My own concern is not projects that can become a pTLP or even a TLP. Such projects are not a problem for the Incubator.. They graduate and don't have growing pains once graduated (or at least no more than if they were to go straight to TLP). This is because they have, by definition, active people in their community that will ensure the project will graduate My concern, which is an IPMC concern, is the few projects that don't have that starting point. The pTLP doesn't solve that problem. It moves it. I've been consistent with that feedback throughout. I'm not sure how Roman interpreted my repeat of that, and a desire to try something else, as me saying pTLP had to happen in the incubator. I didn't say that, at least not intentionally. And in the summary of my position at the start of this thread, a summary I didn't write (that is other people seen to understand my point). So there you have it, I am taking a position. PTLP is fine. Go do it (actually I'm with Sam, drop the p and thus drop the confusion) PTLP doesn't solve the problems identified in the wiki. So whilst it can reduce unnecessary work in the IPMC it wont since the problem. Am I being clear? One more point of clarity. If anyone wants to claim pTLP is all we need, and the IPMC can be dissolved then I have a problem with that. And if someone does claim this then the two things are not orthogonal. Ross Sent from my Windows Phone From: Greg Steinmailto:gst...@gmail.com Sent: 2/24/2015 12:32 AM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Practical next steps for pTLP experiment if we accept ... take a position, Ross. The two problems *are* orthogonal. The IPMC can do whatever it likes. A pTLP is a proposal to the Board. Bertrand would like to see discussion on general@incubator, but that is merely a handy location. It actually has zero to do with the Incubator. Ross: if you believe that a pTLP is somehow tied to the Incubator, then state that. Otherwise, please STOP throwing uncertainty into the waters. -g On Mon, Feb 23, 2015 at 7:29 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Fair enough. I don't think I ever agreed they are orthogonal. In fact the only concern I have consistently stated, and is reflected on the summary below, is that it, potentially, moves the problem rather than solves it. That being said, if we accept its orthogonal then your point is a good one. Sent from my Windows Phone From: Roman Shaposhnikmailto:ro...@shaposhnik.org Sent: 2/23/2015 4:49 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Practical next steps for pTLP experiment On Mon, Feb 23, 2015 at 4:11 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: It's not unfair. I deliberately tried to say i don't want to distract from the handover process. I though we all agreed that whatever pTLP is -- it is absolutely 100% orthogonal to the process that Incubator is in business of managing. There will be some overlap of people involved in both, but we don't need to wait on Incubator to proceed with pTLP any more than we'd need to wait on Incubator to do something in Hadoop land (although quite a few Hadoop folks are on IPMC). I don't think its productive to make someone's support or otherwise of an experiment to distract from getting the right chair to replace you. That would be a fair point if we didn't try as hard as we can to decouple the two. If what you're saying is: currently there's no way for Incubator NOT to be involved in pTLP AND if that's the opinion shared by the majority on the board, I'd have to re-evaluate things on my end. I thought Greg convinced you all that it must be de-coupled. That's what I based my calculations on. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Practical next steps for pTLP experiment
Ok, take ur of the incubator list. Where my only comment is as power my mail below: PTLP is fine. Go do it (actually I'm with Sam, drop the p and thus drop the confusion) Sent from my Windows Phone From: Greg Steinmailto:gst...@gmail.com Sent: 2/24/2015 3:31 AM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Practical next steps for pTLP experiment Stop talking about Incubator changes. You begin with pTLP, but devolve into other proposals about changes to the Incubator. Niclas restarted this thread about pTLP. That is all. On Tue, Feb 24, 2015 at 3:06 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Ok let me try again. I am in support of pTLP where it is clear it will work for a given project. Sam makes a good point that if we are sure it will work why bother. Just make it a TLP and be done with it. This version of orthogonal to the IPMC. I agree and I think its a great idea. My own concern is not projects that can become a pTLP or even a TLP. Such projects are not a problem for the Incubator.. They graduate and don't have growing pains once graduated (or at least no more than if they were to go straight to TLP). This is because they have, by definition, active people in their community that will ensure the project will graduate My concern, which is an IPMC concern, is the few projects that don't have that starting point. The pTLP doesn't solve that problem. It moves it. I've been consistent with that feedback throughout. I'm not sure how Roman interpreted my repeat of that, and a desire to try something else, as me saying pTLP had to happen in the incubator. I didn't say that, at least not intentionally. And in the summary of my position at the start of this thread, a summary I didn't write (that is other people seen to understand my point). So there you have it, I am taking a position. PTLP is fine. Go do it (actually I'm with Sam, drop the p and thus drop the confusion) PTLP doesn't solve the problems identified in the wiki. So whilst it can reduce unnecessary work in the IPMC it wont since the problem. Am I being clear? One more point of clarity. If anyone wants to claim pTLP is all we need, and the IPMC can be dissolved then I have a problem with that. And if someone does claim this then the two things are not orthogonal. Ross Sent from my Windows Phone From: Greg Steinmailto:gst...@gmail.com Sent: 2/24/2015 12:32 AM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Practical next steps for pTLP experiment if we accept ... take a position, Ross. The two problems *are* orthogonal. The IPMC can do whatever it likes. A pTLP is a proposal to the Board. Bertrand would like to see discussion on general@incubator, but that is merely a handy location. It actually has zero to do with the Incubator. Ross: if you believe that a pTLP is somehow tied to the Incubator, then state that. Otherwise, please STOP throwing uncertainty into the waters. -g On Mon, Feb 23, 2015 at 7:29 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Fair enough. I don't think I ever agreed they are orthogonal. In fact the only concern I have consistently stated, and is reflected on the summary below, is that it, potentially, moves the problem rather than solves it. That being said, if we accept its orthogonal then your point is a good one. Sent from my Windows Phone From: Roman Shaposhnikmailto:ro...@shaposhnik.org Sent: 2/23/2015 4:49 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Practical next steps for pTLP experiment On Mon, Feb 23, 2015 at 4:11 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: It's not unfair. I deliberately tried to say i don't want to distract from the handover process. I though we all agreed that whatever pTLP is -- it is absolutely 100% orthogonal to the process that Incubator is in business of managing. There will be some overlap of people involved in both, but we don't need to wait on Incubator to proceed with pTLP any more than we'd need to wait on Incubator to do something in Hadoop land (although quite a few Hadoop folks are on IPMC). I don't think its productive to make someone's support or otherwise of an experiment to distract from getting the right chair to replace you. That would be a fair point if we didn't try as hard as we can to decouple the two. If what you're saying is: currently there's no way for Incubator NOT to be involved in pTLP AND if that's the opinion shared by the majority on the board, I'd have to re-evaluate things on my end. I thought Greg convinced you all that it must be de-coupled. That's what I based my calculations on. Thanks, Roman
RE: Practical next steps for pTLP experiment
The board have asked for the IPMC to make recommendations. Sent from my Windows Phone From: Roman Shaposhnikmailto:ro...@shaposhnik.org Sent: 2/23/2015 3:46 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Practical next steps for pTLP experiment On Mon, Feb 23, 2015 at 12:12 AM, Niclas Hedhman nic...@hedhman.org wrote: I would like to pick this thread up again... Thanks! I apologize for being completely unavailable for the past 10 days or so -- the amount of stuff happening @$WORK was way too overwhelming. As a matter of fact, my biggest surprise was the fact that it didn't feel like the board ended up discussing pTLP at all last week. I was under the impression that we were expecting this to be the next step in this whole process. What gives? Am I not looking at the right place for notes (apologies -- like I said -- I'm still not 100% back from last week). Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Practical next steps for pTLP experiment
Fair enough. I don't think I ever agreed they are orthogonal. In fact the only concern I have consistently stated, and is reflected on the summary below, is that it, potentially, moves the problem rather than solves it. That being said, if we accept its orthogonal then your point is a good one. Sent from my Windows Phone From: Roman Shaposhnikmailto:ro...@shaposhnik.org Sent: 2/23/2015 4:49 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Practical next steps for pTLP experiment On Mon, Feb 23, 2015 at 4:11 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: It's not unfair. I deliberately tried to say i don't want to distract from the handover process. I though we all agreed that whatever pTLP is -- it is absolutely 100% orthogonal to the process that Incubator is in business of managing. There will be some overlap of people involved in both, but we don't need to wait on Incubator to proceed with pTLP any more than we'd need to wait on Incubator to do something in Hadoop land (although quite a few Hadoop folks are on IPMC). I don't think its productive to make someone's support or otherwise of an experiment to distract from getting the right chair to replace you. That would be a fair point if we didn't try as hard as we can to decouple the two. If what you're saying is: currently there's no way for Incubator NOT to be involved in pTLP AND if that's the opinion shared by the majority on the board, I'd have to re-evaluate things on my end. I thought Greg convinced you all that it must be de-coupled. That's what I based my calculations on. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Practical next steps for pTLP experiment
It's not unfair. I deliberately tried to say i don't want to distract from the handover process. How you would want to handle things is not necessarily the way the incoming chair wants to handle things. By delaying the discussion until afterwards I merely want to give the incoming chair a chance to have their input, as chair. I don't think its productive to make someone's support or otherwise of an experiment to distract from getting the right chair to replace you. As for what's needed - that's simple a recommendation to the board which Iis clear an unambiguous. We are not there yet, we don't have consensus here. I believe we don't have consensus because we haven't tried things to provide data. Sent from my Windows Phone From: Roman Shaposhnikmailto:ro...@shaposhnik.org Sent: 2/23/2015 3:52 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Practical next steps for pTLP experiment On Mon, Feb 23, 2015 at 3:48 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: We don't need consensus from the board. We need data to allow the board to evaluate properly. That's fair, but what *exactly* do you need? The IPMC is tasked with providing recommendations. Personally I'm waiting for the disruption a chair change brings to settle down and will then look forward to helping with some experimentation Wow! That's kind of unfair. What disruption are you talking about? There will be a VOTE thread this week (now that I'm back to start it) and I haven't seen much disruption *at all*. Saying that pTLP is somehow blocked on this imaginary 'disruption' thing feels really weird. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Practical next steps for pTLP experiment
Board@ discussions Sent from my Windows Phone From: Roman Shaposhnikmailto:ro...@shaposhnik.org Sent: 2/23/2015 3:53 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Practical next steps for pTLP experiment On Mon, Feb 23, 2015 at 3:48 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: The board have asked for the IPMC to make recommendations. Is the precise nature of what being asked recorded anywhere? Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Practical next steps for pTLP experiment
We don't need consensus from the board. We need data to allow the board to evaluate properly. The IPMC is tasked with providing recommendations. Personally I'm waiting for the disruption a chair change brings to settle down and will then look forward to helping with some experimentation (I don't plan pTLP like experiments, I have my own ideas expressed elsewhere on this list, but your summary of my views on pTLp is a fairly accurate representation). Ross Sent from my Windows Phone From: Niclas Hedhmanmailto:nic...@hedhman.org Sent: 2/23/2015 12:14 AM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Practical next steps for pTLP experiment I would like to pick this thread up again... IIUIC (sorry in advance if I grossly misrepresent opinion), the various views that exists can be attributed to the following Board members; Greg, Chris -- Would like to have Provisional badge, which entails disclaimers to alert users. Sam -- Think there is no need for a new concept, and have no problem with incoming projects backed by ASF veterans to bypass the Incubator. Bertrand -- Doesn't want a new concept for the Board to deal with. Suggests to run pTLP under the Incubator supervision. Doug -- Don't want to see more vectors for Board, as any future change to lower burden on Board will be made complex. He favor a pure TLP status from Board's perspective, but have no problem with voluntary labeling at the TLP itself. Jim -- Was worried about the wording (run) that implied more work for Board. Greg clarified the meaning to not imply such. Jim is mulling over the pTLP concept not seeming/feeling right, and worries about just do it, document later approach. Ross -- Expressed hope that pTLP will reduce load on IPMC, but warn possible burden on Board if something goes wrong. Seems positive to experiments to gather data. At least superficially, it seems that there is no consensus at the Board level at this point in time. It is difficult to gauge whether a consensus in favor can be reached, or that this idea should be dropped. Opinions? Niclas On Wed, Feb 11, 2015 at 4:18 PM, Greg Stein gst...@gmail.com wrote: On Tue, Feb 10, 2015 at 4:01 PM, Sam Ruby ru...@intertwingly.net wrote: On Tue, Feb 10, 2015 at 3:35 PM, Greg Stein gst...@gmail.com wrote: Who ever said the Incubator has the exclusive Right to be the only way to become part of the Apache Software Foundation? New approaches can be discussed anywhere. At the end of the day, it will be the Board who votes on a pTLP resolution. Resolution R2, paragraph 3: http://apache.org/foundation/records/minutes/2002/board_minutes_2002_10_16.txt Well aware, Sam. I voted on that. ... and again: it doesn't assign *exclusive* management of incoming projects. It is flat out impossible for such. The Board can write a resolution saying that one day, and then accept a contravening resolution the next. *shrug* ... what you're missing is that pTLP is not part of the Incubator. Nothing against it, but it has zero bearing upon these proposals. All of that is left to the Board. ... Cheers, -g -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java
RE: Practical next steps for pTLP experiment
ComDev docs are in the CMS. All committers have write access. PMC members have publish access. Ross -Original Message- From: Greg Stein [mailto:gst...@gmail.com] Sent: Tuesday, January 27, 2015 10:56 AM To: general@incubator.apache.org Subject: Re: Practical next steps for pTLP experiment On Tue, Jan 27, 2015 at 12:38 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: ... Totally agreed! Who can help me learning the ropes on how ComDev documentation is maintained, etc? Maybe ask on dev@community rather than general@ ?? :-P - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [DISCUSS] Solicitation for IPMC Chair nomination
+1 (and on a personal note, thank you for making possible to, once again, avoid throwing my own hat into the ring). Ross -Original Message- From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] Sent: Tuesday, January 27, 2015 12:32 PM To: Incubator General Subject: Re: [DISCUSS] Solicitation for IPMC Chair nomination On Tue, Jan 27, 2015 at 9:19 PM, Ted Dunning ted.dunn...@gmail.com wrote: ...I would be happy and enthusiastic to help by working with the Incubator project in this role +1, thanks! We have a growing number of survivors who demonstrate that it's possible to do a great job as an Incubator PMC chair without losing your sanity (at least not completely ;-). Looking forward to another one! -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: my pTLP view
It's an *option* not the only route. Working for some but not others is just fine. Ross -Original Message- From: Alex Harui [mailto:aha...@adobe.com] Sent: Monday, January 26, 2015 11:23 AM To: general@incubator.apache.org Cc: Chris Mattmann; Jim Jagielski Subject: Re: my pTLP view I can see how it could work for some new communities, but I don’t think it will work for all. I would imagine some potential podlings don’t have well-established communities. They might just be a few folks with a good idea and looking to recruit lots of new folks for the initial committers list. In such a case, it sort of makes sense for there to be an option, if enough ASF members want to be on that initial committers list not to mentor, but to be real committers, for the board to bypass incubation and establish a pTLP. For Flex, we did not have an established community of developers coming in with the code. But I don’t know that we could have recruited enough ASF members to be committers. Flex was different enough to not be closely related to any other Apache project. Folks were interested in seeing if Flex could be a viable Apache project, but I don’t think any existing ASF members have actually become Flex committers. I think I’ve processed new accounts for each of our committers. So would that mean that some future Flex would just not come to Apache? On 1/26/15, 10:09 AM, Alan D. Cabrera l...@toolazydogs.com wrote: TL;DR I think this is a good idea. I thought long and hard about this during the weekend and I’ve changed my mind about this; I’ll spare you my handwringing thought processes. Some things that I personally would like to see: - do away w/ the pTLP name, just make it a regular TLP - ComDev should be charged w/ augmenting their maturity model with “profiles” which can be applied to such TLPs, e.g. - committers==PMC - codebase going through IP clearance - PMC considers TLP properly diverse - PMC considers TLP properly active - item 2 is too strict Regards, Alan On Jan 23, 2015, at 5:42 AM, Greg Stein gst...@gmail.com wrote: Roman kicked off a query about next steps, with links to several wiki pages on possibilities. The IncubatorV2 page which describes a probationary TLP is nothing like I have thought about. In my mind, a pTLP looks *exactly* like any other PMC. They report directly to the Board, they have infrastructure like any other project (eg. FOO.apache.org). But they have two significant differences: 1. probationary text is prominent, much like we require incubating to be prominent in various locations/messages for podlings 2. the initial PMC is comprised of only ASF Members. committers can be chosen however the community decides. but the *project* is reviewed by people with (hopefully/theoretically) experience with the Foundation and its views on communities That's it. By creating a PMC that understands what is needed, then they can groom new PMC members, and use the standard process for adding them to the PMC. The Board doesn't care about committership, so the pTLP can do whatever it wants in that regard. The Board might not accept a pTLP resolution because it wants more greybeards on there, to help the community. Removing the probationary label, is up to the pTLP to request, and the Board to approve. It is usually pretty obvious when a community has reached that point, if you are talking about active ASF/PMC Members. But the Board would apply its own level of trust. There is a big element here, which didn't exist 12 years ago: the Board's ability to review many projects. Before the Incubator, there weren't that many projects. The Directors didn't have a lot of experience with a lot of breadth. Nowadays, we review the work of *dozens* of projects every month. If one is a pTLP instead of a regular TLP? Not a big deal. They have some operational restrictions, but the report should be showing us a typical Apache community. The other aspect is IP clearance and management, which also didn't exist a dozen years ago (and the Incubator was basically started in response to some IP problems). We have a much better understanding there. Today, we have the Incubator performing that, but no reason we can't have pTLPs managing that process. We file forms about clearance with the Incubator, but really: that should be filed $somehow defined by the VP of Legal Affairs (and *that* position/process didn't exist until years after the Incubator was established). TLPs are a recognition of a community. We can create probationary communities, supported by ComDev, Legal, other communities, and reviewed by the Board. Speaking as a Director of the ASF, if a Resolution arrived on the Board's Agenda to create such a pTLP, then I would be supportive. The pTLP construct is independent of the Apache Incubator. Anybody is free to define how they want to approach it, and then ask
RE: my pTLP view
And even in the strawman (at least how I wrote it) there is even less of a gap from today's model to the pTLP proposal under discussion here. Sent from my Windows Phone From: Greg Steinmailto:gst...@gmail.com Sent: 1/25/2015 12:03 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: my pTLP view Go to the FIRST POST of this thread (titled: my pTLP view!!). THAT is what we're talking about. Not the Strawman. On Sun, Jan 25, 2015 at 1:56 PM, Andrew Purtell apurt...@apache.org wrote: Oh, my mistake! (smile) I confused pTLP with the Strawman proposal there for a minute. In the pTLP proposal, there are no new-to-the-Foundation project members on the pTLP PMC. All proposals for new ASF projects must include an initial PMC chair and an initial set of PMC members. These people must be acceptable to the board. It is the responsibility of the Incubator Committee to vett these people. All of them must have experience on existing PMCs Newcomers to Apache *might* get committership depending how the only-members-as-PMC decide. They don't get even non-binding stakeholdership in decisionmaking on new commiters, releases, and so on. On Sun, Jan 25, 2015 at 11:49 AM, Andrew Purtell apurt...@apache.org wrote: This is *exactly* the way things work in a TLP. Yes, everyone new to the Foundation on the PPMC has a sense of equal ownership in the process. The PPMC makes a decision together as equals, then the decision is reviewed as a whole. But this is not how things would work in a pTLP, right? Individuals there would effectively cast votes +1 (binding), or -1 (binding), +1 (non-binding), or -1 (non-binding), etc., depending if they are a Member or not. Maybe in practice the pTLP PMC wouldn't write down their votes like that, but somehow the distinction must be presented in the tallies to be meaningful. On Sun, Jan 25, 2015 at 11:11 AM, Branko Čibej br...@apache.org wrote: On 25.01.2015 19:51, Andrew Purtell wrote: That hardly ever happens (it's most likely when there are problems with a podling's first few releases), which is why you get the impression that the PPMC can make binding decisions. Close. The PPMC membership feels they have made a decision that matters with equal input. Certainly on PPMCs I've been on, there is awareness that everything is provisional . Still, a process takes place on PPMC mailing lists leading to a tallied outcome. The input that leads to this output is the consensus or voting of *a group of equal peers*. This output is handed to the IPMC in aggregate. When casting votes on the PPMC lists there are no +1 (binding) or +1 (non-binding) distinctions made. PPMC sends the outcome over to the IPMC feeling some level of ownership having just participated in a decision making process as equal s . (Or at least so I think, in some perhaps quaint notion.) Of course in IPMC voting it is different, but the IPMC is where supervision happens, or doesn't, as some argue. This is *exactly* the way things work in a TLP. Any committer can propose a release. The PMC must (!) start a (public) vote. Anyone can vote, with PMC votes being binding. /Any/ -1 vote, either from PMC member or plain committer, should block the release and trigger a discussion to find a solution; and in this discussion (which purpose is to reach consensus on a solution), PMC members have no more voice than any other community member. If the PMC decides to ignore a -1 on a release vote, they'd better have really good reasons for that, or I'd expect the Board to come down like a ton of bricks on that PMC. The situation is slightly different with new committer/PMC member nominations and votes, which are private; you have a point there. -- Brane On Sun, Jan 25, 2015 at 10:35 AM, Branko Čibej br...@apache.org wrote: On 25.01.2015 19:16, Andrew Purtell wrote: With a PPMC we invite newcomers to make votes we call binding on matters of their own project. As other people have said, PPMC members (that are not also IPMC members) do not have binding votes, neither for releases nor for inviting new committers/PPMC members. The binding bit lies with the IPMC, which can revoke any formal decision made by the PPMC. That hardly ever happens (it's most likely when there are problems with a podling's first few releases), which is why you get the impression that the PPMC can make binding decisions. In this respect, there's no practical difference between the current IPMC model and the proposed pTLP model. Of course, when it comes to /technical/ decisions, there's no such thing as a vote, so the term binding does not apply. Consensus, of one form or another, always rules: and the IPMC or mentors can't meddle in this case. -- Brane
RE: my pTLP view
A good mentor is a guide, not a manager. The proposals might seem top down, but when executed correctly, they are not. Sent from my Windows Phone From: Alex Haruimailto:aha...@adobe.com Sent: 1/23/2015 12:06 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Cc: Chris Mattmannmailto:mattm...@apache.org; Jim Jagielskimailto:j...@jagunet.com Subject: Re: my pTLP view On 1/23/15, 6:53 AM, jan i j...@apache.org wrote: I agree with everything else you write, but the demand for only ASF Members seems very hard. If I come to ASF with a community and a project, I really would feel unhappy being cut out of the loop Time for my weekly musings. Sorry, no oaths and anthems this week. I agree with Jan I. Thinking back only a few years to when I was new to Apache and going through the incubator, if the original PMC was comprised only of seasoned ASF folks, I would have felt more like those ASF folks were my managers and been more passive about learning about Apache because I would expect these authority figures to train me. Sometimes the better way to learn is by doing. IMO, it is better to make folks who really have a stake in the success of the project feel that responsibility. To me, that’s the problem I’ve having with all of these proposals. They seem too “top-down”, like the podling is a baby in need of true incubation, like hand-holding and feeding. Really, a podling is made up of adults and “all I think you really need is to make it clear to newcomers that there is a different culture at Apache and that you are expected to understand it, exercise it, and propagate it to latecomers in order to become a full Apache project. I just think that coddling newcomers takes the risk of creating newcomers that can’t stand on their own legs. IMO, you want to test the newcomers to make sure they can perform autonomously and proactively. Maybe instead of the name “Incubator” we should call it “University”. Lots of businesses send new employees to a “University” where corporate culture is part of the lessons. But even that is “top-down” like you are expected to go to class. How about “Driving School”? In driving school you drive the car and get advice. The instructor only takes control in an emergency. And the culture around driving, the “unwritten rules of the road” that aren’t in the instruction manual, is part of what you learn while you are doing. New Apache instruction manuals are being written by Marvin and Bertrand et al, so the rest comes down to “How do you teach culture?” I’ve never moved to another country to live, but I would argue that I had to learn a new culture when I left my west coast high school and went to Boston for college. You can write up your culture and folks can read it, but a lot of it just comes from trying it and being corrected as soon as possible, hopefully in a nice way. So let the newcomers drive. Now, how do you make sure there is an instructor in the car, that instructors are paying attention, and are teaching the right rules? If your driving instructor is a New York City cab driver, you would get a decidedly different outcome than if the driving instructor was my mom. I think I’m hearing in these threads that there is too much variance in the instruction at Apache. Culling back to a core that truly gets it and training new instructors might be required if that’s true. In driving school, the instructor in the car has a significant stake in the outcome. He/she truly has “skin in the game”. I don’t see any easy way for our mentors to have the same stake, especially given they are volunteers. In real communities, cultural errors are caught by the villagers being embedded. They see you doing something you shouldn’t take you aside and tell you what you need to do differently. The thing is, there are usually few newcomers and lots of villagers. New projects usually overwhelm the villagers/mentors with new folks. Maybe a solution is even more ASF folks on each podling’s list. Sure that dilutes responsibility, but with volunteers, responsibility is always difficult to require. Volunteer-staffed house-building project coordinators don’t try to find a few volunteers to commit whole days, they try to find dozens of volunteers knowing each might only hammer a few nails before leaving, but collectively things get done. The Incubator has one solution in place already. Certain podling tasks require notification before you get started on them and final approval when you finish. Maybe more podling tasks like report writing and discussing potential committers need to follow the same pattern. Maybe podlings should be encouraged to notify the incubator when the temperature of a discussion rises, or maybe we need a tool that notifies the villagers/incubators/members when any podling thread grows over 10 posts. And if you have the right notifications, you get one other benefit. If a podling doesn’t emit any
RE: my pTLP view
As ASF member *should* know that empowering the ones doing the work is the Apache Way. A good member who is a mentor will ensure that they unblock anything that prevents those doing the work having the influence. Look, theoretically, the board have ultimate power over all the projects at the ASF. According to the byelaws the board can do anything they want. Taking that logic a step further the president can unilaterally do almost anything they want. We avoid this situation by only electing people into those positions who are not going to abuse that power and instead use it to empower those doing the work. I repeat again a good mentor is nothing more than a guide. So why not make the project community the ones with the authority of a PMC? Two main reasons, that I can see: a) we don't know the newcomers - how can we be sure they we not misuse heir power? b) they hold the keys to the release process, that's what protects the contributors legally, we can’t remove that The pTLP proposal does not change the way things work today. The incoming community don't have any voting authority - it's with the mentors and the IPMC. All that being said, while I will (and already did two years ago) support some experimentation with the pTLP model I still feel that an Incubator with teeth scales better. Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: jan i [mailto:j...@apache.org] Sent: Friday, January 23, 2015 2:34 PM To: general@incubator.apache.org Subject: my pTLP view On Friday, January 23, 2015, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com javascript:_e(%7B%7D,'cvml','ross.gard...@microsoft.com'); wrote: A good mentor is a guide, not a manager. The proposals might seem top down, but when executed correctly, they are not. No offense but how can you not call it top down, when the people trusted by the original community is removed and replaced by a bunch of potentially unknown people? Having only ASF members is nearly the sane as saying hi guys, we accept your project if you let us take over, and we ask you not do community (only committer) work until WE deem you worthy of building YOUR community. Remember the difference between committer and PMC please. The PPMC today plays an important role and you just remove it, and think ASF members can replace that without looking at the effect such an action will have. Not having the original community in the PMC, also means the original community looses totally control over what is being releasedis that really fair? Sorry this is not the ASF I work for an strongly believe in. A project that comes to ASF with a community has a right to continue evolve its community as PMC with its own trusted people, and we as members need to HELP them if they have problems in the apache way NOT replace them. I really think you need to look at this from both sides and replace control/babysitting with help/guidance. Sorry for this strong worded mail, but I really feel we risk ruining everything we stand for. jan i Sent from my Windows Phone From: Alex Haruimailto:aha...@adobe.com Sent: 1/23/2015 12:06 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Cc: Chris Mattmannmailto:mattm...@apache.org; Jim Jagielskimailto: j...@jagunet.com Subject: Re: my pTLP view On 1/23/15, 6:53 AM, jan i j...@apache.org wrote: I agree with everything else you write, but the demand for only ASF Members seems very hard. If I come to ASF with a community and a project, I really would feel unhappy being cut out of the loop Time for my weekly musings. Sorry, no oaths and anthems this week. I agree with Jan I. Thinking back only a few years to when I was new to Apache and going through the incubator, if the original PMC was comprised only of seasoned ASF folks, I would have felt more like those ASF folks were my managers and been more passive about learning about Apache because I would expect these authority figures to train me. Sometimes the better way to learn is by doing. IMO, it is better to make folks who really have a stake in the success of the project feel that responsibility. To me, that’s the problem I’ve having with all of these proposals. They seem too “top-down”, like the podling is a baby in need of true incubation, like hand-holding and feeding. Really, a podling is made up of adults and “all I think you really need is to make it clear to newcomers that there is a different culture at Apache and that you are expected to understand it, exercise it, and propagate it to latecomers in order to become a full Apache project. I just think that coddling newcomers takes the risk of creating newcomers that can’t stand on their own legs. IMO, you want to test the newcomers to make sure they can perform autonomously and proactively. Maybe instead of the name “Incubator
RE: my pTLP view
+1 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: Friday, January 23, 2015 2:51 PM To: general@incubator.apache.org Subject: Re: my pTLP view On Fri, Jan 23, 2015 at 2:47 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: All that being said, while I will (and already did two years ago) support some experimentation with the pTLP model I still feel that an Incubator with teeth scales better. But we wouldn't know until we try. And that's why I'd be proposing the two prong approach over the weekend (once I have time to catch up with all the feedback). The two can be tried in parallel. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: my pTLP view
No, the PMC is *not* the driving force. The project community is, even where the PMC is a subset of the committers. Since it is the set of active *contributors* that are important, they are the ones doing the work. I don't understand your argument about releases. Nothing changes under under the pTLP proposal with respect to how a release is made. In any ASF project the full community votes for a release if they want to. Only the PMC have binding votes, but they should listen to the community in casting those votes (same is true for podlings where the podling community votes on a release but it needs to be formalized by the IPMC via its mentors). Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: jan i [mailto:j...@apache.org] Sent: Friday, January 23, 2015 3:21 PM To: general@incubator.apache.org Subject: Re: my pTLP view On Friday, January 23, 2015, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: As ASF member *should* know that empowering the ones doing the work is the Apache Way. A good member who is a mentor will ensure that they unblock anything that prevents those doing the work having the influence. correct, and any ASF member knows that that PMC is the driving community force, we even define the difference roles of committer and PMC like that. Look, theoretically, the board have ultimate power over all the projects at the ASF. According to the byelaws the board can do anything they want. Taking that logic a step further the president can unilaterally do almost anything they want. We avoid this situation by only electing people into those positions who are not going to abuse that power and instead use it to empower those doing the work. and I agree to that, but I cannot see the board force a release, whereas a PMC full of only ASF members would have to do it, because only the PMC is responsible for releases with its votes. I repeat again a good mentor is nothing more than a guide. So why not make the project community the ones with the authority of a PMC? Two main reasons, that I can see: a) we don't know the newcomers - how can we be sure they we not misuse heir power? b) they hold the keys to the release process, that's what protects the contributors legally, we can’t remove that The pTLP proposal does not change the way things work today. The incoming community don't have any voting authority - it's with the mentors and the IPMC. I am sorry but unless I have misunderstood something, the full PPMC votes for a release and then the IPMC vote to accept or reject it. With the pTLC proposal ASF members (the PMC) suggest and accept the release, actually they can theoretically force a release without asking a single person in the original community. This proposal cuts out the PPMC vote, and let ASF members decide when a release is to be made. We have a good way today where the community (PPMC) suggest and vote for a release and the IPMC accept/reject the release. All that being said, while I will (and already did two years ago) support some experimentation with the pTLP model I still feel that an Incubator with teeth scales better. +1 rgds jan i Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: jan i [mailto:j...@apache.org javascript:;] Sent: Friday, January 23, 2015 2:34 PM To: general@incubator.apache.org javascript:; Subject: my pTLP view On Friday, January 23, 2015, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com javascript:; javascript:_e(%7B%7D,'cvml',' ross.gard...@microsoft.com javascript:;'); wrote: A good mentor is a guide, not a manager. The proposals might seem top down, but when executed correctly, they are not. No offense but how can you not call it top down, when the people trusted by the original community is removed and replaced by a bunch of potentially unknown people? Having only ASF members is nearly the sane as saying hi guys, we accept your project if you let us take over, and we ask you not do community (only committer) work until WE deem you worthy of building YOUR community. Remember the difference between committer and PMC please. The PPMC today plays an important role and you just remove it, and think ASF members can replace that without looking at the effect such an action will have. Not having the original community in the PMC, also means the original community looses totally control over what is being releasedis that really fair? Sorry this is not the ASF I work for an strongly believe in. A project that comes to ASF with a community has a right to continue evolve its community as PMC with its own trusted people, and we as members need to HELP them if they have problems in the apache way NOT replace them. I really think you need to look at this from both sides and replace control
RE: my pTLP view
What makes you think the PPMC today had more influence than the contributors to a pushing? Votes have been mentioned, but votes remain the same. Despite what people on this thread are saying PPMC members do not have a binding vote. That does not change. Besides, the whole thing is moot because pTLP is an *option* Sent from my Windows Phone From: Andrew Purtellmailto:apurt...@apache.org Sent: 1/23/2015 6:09 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: my pTLP view You are approaching this question with complete trust and faith in the Apache process, being an Apache member, but an incoming / foreign community will not have this, not universally. Take the emotion out of this, because I certainly am not being emotional here, but instead trying to evaluate this change from the perspective of an outsider. I assume the objective is to be and remain an inviting place for building community and code, attracting new blood. I think everyone can accept an organization has a Board with a final say. What I find attractive about the current incubation model is Apache welcomes new communities by making them voting stakeholders in their new project, they become a PPMC, a podling. Sure, the IPMC provides oversight, and the board again, but the PPMC can make binding votes on committers, releases, everything that matters - provisionally, of course, which is completely acceptable. This all changes if the PMC does not include any members of the incoming community. There isn't even a provisional ownership stake in the endeavor. When Apache grants the incoming community a provisional binding stake in the process, this establishes trust. I don't agree that the chances ASF PMC members of pTLP will start actively overriding votes is slim to none. I've been around here for a while and spent some time in Hadoop land. The process is not infallable. The membership is not infallable. To ensure the probability of better outcomes no matter what happens during an incubation, the incoming community should be treated more like partners in a common endeavor with a full stake in the process than what is proposed here. The incoming community is disempowered and has no recourse but to go along with the outcome of Apache politics or abandon the project. How is this not true? What can the incoming community make a binding vote on, under this proposal? On Fri, Jan 23, 2015 at 5:53 PM, Roman Shaposhnik r...@apache.org wrote: On Fri, Jan 23, 2015 at 5:42 PM, Andrew Purtell apurt...@apache.org wrote: Those of us in such a new incoming community might get the commit bit but can't vote on adding committers, See my reply to Jan. C == PPMC solves this completely. or making releases. This is *exactly* what is happening today with every single poddling. Why are you bringing this up as a *new* concern around pTLP? We don't have a binding vote on our own committership / fate / ability to manage our own sources. I'll be a stickler here: literally the only new issue that doesn't exist today is that there won't be a by-law guaranteeing community that they can *override* ASF members vote on new committers. That is it! Everything else stays *exactly* the same. Not a single change to how IPMC *rules* are structured. This situation is primed for mistrust, conflict, and heartache the second the members and the incoming community disagree about some substantial aspect of the project direction. The incoming community is disempowered and has no recourse but to go along with the outcome of Apache politics or abandon the project. As a responsible steward of my community, I would never consider bringing my project to Apache under these circumstances. Wow! This is a pretty gross overstatement if you ask me. Remember, all of the above is predicated on a *single* possibility. Not even a guarantee a *possibility*. That ASF PMC members of pTLP will start actively overriding votes on adding new members to the community. This is literally *the only* power they will be getting that doesn't exist in IPMC today. The chances of that are slim to none, so I have no choice but to call the above a strawman. This may also increase the risk a project is coming here due to an excessive fascination with the Apache brand, because otherwise the bargain seems poor (in my view). Like I said -- we won't know until we try. We will try with *willing* participants. If they like it and if the board likes it -- we will start migrating folks. If not -- we'll stop. Thanks, Roman. P.S. This is my time to apologize for harsh tone. But really? Really: The incoming community is disempowered and has no recourse but to go along with the outcome of Apache politics or abandon the project. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional
RE: my pTLP view
I would support it as an experiment. I will support it because it is one of the few actionable suggestions on the table. My caution has been expressed elsewhere. So I'll summarize as a reminder: 1) I supported just such an experiment a couple of years ago. It didn't go well (not disastrous, but not as expected). This is different from the original experiment as it removes the IPMC completely, but it wasn't the IPMC that was a problem. 2) Changing the oversight body doesn't magically make mentors as attentive as they need to be. There is *much* more work in fixing the problem than changing the oversight role. Neither of these items mean pTLP will fail. I am supportive of the proposal as long as there is sufficient examination of the PMC membership on creation (which I see no reason to doubt). Ross Sent from my Windows Phone From: Chris Mattmannmailto:mattm...@apache.org Sent: 1/23/2015 7:18 AM To: Greg Steinmailto:gst...@gmail.com; general@incubator.apache.orgmailto:general@incubator.apache.org; Chris Mattmannmailto:mattm...@apache.org; Jim Jagielskimailto:j...@jagunet.com Subject: Re: my pTLP view +1000. My view too and with my support too. -Original Message- From: Greg Stein gst...@gmail.com Date: Friday, January 23, 2015 at 5:42 AM To: general@incubator.apache.org general@incubator.apache.org, Chris Mattmann mattm...@apache.org, Jim Jagielski j...@jagunet.com Subject: my pTLP view Roman kicked off a query about next steps, with links to several wiki pages on possibilities. The IncubatorV2 page which describes a probationary TLP is nothing like I have thought about. In my mind, a pTLP looks *exactly* like any other PMC. They report directly to the Board, they have infrastructure like any other project (eg. FOO.apache.org http://FOO.apache.org). But they have two significant differences: 1. probationary text is prominent, much like we require incubating to be prominent in various locations/messages for podlings 2. the initial PMC is comprised of only ASF Members. committers can be chosen however the community decides. but the *project* is reviewed by people with (hopefully/theoretically) experience with the Foundation and its views on communities That's it. By creating a PMC that understands what is needed, then they can groom new PMC members, and use the standard process for adding them to the PMC. The Board doesn't care about committership, so the pTLP can do whatever it wants in that regard. The Board might not accept a pTLP resolution because it wants more greybeards on there, to help the community. Removing the probationary label, is up to the pTLP to request, and the Board to approve. It is usually pretty obvious when a community has reached that point, if you are talking about active ASF/PMC Members. But the Board would apply its own level of trust. There is a big element here, which didn't exist 12 years ago: the Board's ability to review many projects. Before the Incubator, there weren't that many projects. The Directors didn't have a lot of experience with a lot of breadth. Nowadays, we review the work of *dozens* of projects every month. If one is a pTLP instead of a regular TLP? Not a big deal. They have some operational restrictions, but the report should be showing us a typical Apache community. The other aspect is IP clearance and management, which also didn't exist a dozen years ago (and the Incubator was basically started in response to some IP problems). We have a much better understanding there. Today, we have the Incubator performing that, but no reason we can't have pTLPs managing that process. We file forms about clearance with the Incubator, but really: that should be filed $somehow defined by the VP of Legal Affairs (and *that* position/process didn't exist until years after the Incubator was established). TLPs are a recognition of a community. We can create probationary communities, supported by ComDev, Legal, other communities, and reviewed by the Board. Speaking as a Director of the ASF, if a Resolution arrived on the Board's Agenda to create such a pTLP, then I would be supportive. The pTLP construct is independent of the Apache Incubator. Anybody is free to define how they want to approach it, and then ask the Board if they are willing to try it. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
To confirm I was referring to TLPs, personally I don't spend anywhere near as much time on podling reports, as Bertrand indicates that's delegated today. Sent from my Windows Phone From: Bertrand Delacretazmailto:bdelacre...@apache.org Sent: 1/23/2015 1:22 AM To: Incubator Generalmailto:general@incubator.apache.org Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.) On Thu, Jan 22, 2015 at 4:18 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: The board do take on such an active task I'm not sure what you mean exactly - IMO board members do pay close attention to TLP reports (in more or less detail depending on our perception of the project's health), but we might not look at each podling report in as much detail. The board has delegated management of podlings to the Incubator PMC, so IMO it's fine for board members to just look at the Incubator summary report, and mostly skim through podling reports, maybe look more closely at a few that stand out for some reason. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
In the thread Incubator report sign-off I posted a mail at Mon 1/5/2015 4:34 PM, it has the following content (edited for brevity here) Let's think about the work a Director should do when reviewing a report. It’s not reading the report and then ticking a box. It's reading a report, comparing it to previous reports. Taking a quick look at the tone of emails on the dev list. Looking at commit activity. Checking the private list is not too active and more. We have some great tools (thanks Sam) for helping with this process, but it's still time consuming. We also have the concept of Shepherds. Those shepherds are expected to fully review a projects report and status. They will typically spend 10 minutes more than other directors and will be able to answer any questions that come up in the meeting from other directors. To really review a project properly takes a good 10 mins for non-shepherds and 20-30 minutes for shepherds (at least that is how long *I* spend on each report, I think most, if not all, directors would say the same). This is the case if there is no difficulties. If there are difficulties you can be talking about hours. As an example of how long it takes to decide whether or not action is taken let me give you two concrete examples. Last night I spent just over four hours reviewing the archives of a TLP to see if a potential problem was actually a problem. I've spent maybe another 2 hours in email threads on the topic. For another project a different director has spent what I would estimate to be at least three hours reviewing and addressing an issue while I've spent maybe an hour tracking those threads to see if I need to help out. That's just in the last week, just the items I'm aware of and it doesn't address other things the directors do on a weekly basis. Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Marvin Humphrey [mailto:mar...@rectangular.com] Sent: Thursday, January 22, 2015 10:39 AM To: general@incubator.apache.org Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.) On Thu, Jan 22, 2015 at 7:18 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: The board do take on such an active task. As someone who has been subscribed to board@apache for a long time and has attended many monthly Board meetings, this catches me off guard. I will follow Board report commentary with a different eye in the future... Whatever our expectations are for the Incubator's shepherds, the institution is slowing dying. Past contributors have fallen away and recruitment drives have not yielded sufficient replacements. And so what? Simply by maintaining monthly tags in podlings.xml when podlings don't report or no Mentors sign off, the Report Manager can handle the essential task that the shepherds can no longer be counted on for: ensuring that we don't lose track of wayward podlings. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
The board do take on such an active task. Sent from my Windows Phone From: Niclas Hedhmanmailto:nic...@hedhman.org Sent: 1/21/2015 11:08 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.) Ted, doesn't that then suggest that the Board should do such an active task as well, since they thus can spot common problems easily? But they don't, possibly due to it doesn't scale. Their man on the field, the VP, is trusted to have a grip on the situation. Why doesn't IPMC trust that the mentor(s) has a grip as its man on the field. Isn't what you describe another mentor with a different engagement level... Cheers Niclas On Thu, Jan 22, 2015 at 11:17 AM, Ted Dunning ted.dunn...@gmail.com wrote: On Wed, Jan 21, 2015 at 5:03 PM, Marvin Humphrey mar...@rectangular.com wrote: Statements like shepherds dilute mentor responsibility are false. A shepherd provides a mechanism for the IPMC to review the Podling/Mentor relationship. This is something the IPMC needs to do when voting to graduate a podling. We should be ALL be doing shepherding work. I can see what Alan's getting at, though. Unless the podling is in trouble, the podling contributors ought to be writing the report. The people who are then best placed to give informed feedback on that report are the podling's Mentors. But instead, the people who provide commentary on the state of the podling community tend to be the shepherds, whose understanding is necessarily more superficial. Doesn't that seem strange? Actually, I don't see it as strange. More than once while I was actively mentoring a project, a shepherd dropped in and noticed something that neither the project nor I had been focussing on. The mentor (me) was very actively involved in helping the community but the shepherd distinctly added value. Shepherds see across many projects and thus can spot common problems easily. Mentors focus on a few problems and thus can spot longer-term problems. The difference works really well in my experience. At least I know that I was able to mentor better with the help. -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
No harm done Marvin :-) Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Marvin Humphrey [mailto:mar...@rectangular.com] Sent: Thursday, January 22, 2015 11:13 AM To: general@incubator.apache.org Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.) On Thu, Jan 22, 2015 at 10:47 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: In the thread Incubator report sign-off I posted a mail at Mon 1/5/2015 4:34 PM, it has the following content (edited for brevity here) Acknowledged. I apologize for mischaracterizing the effort that Board members such as yourself put in. It was surely not my intent to diminish your efforts, I simply believed the workflow to be more reactive than proactive. None of this changes any of my commentary on the state of Incubator shepherds, and I hope that the offense given was not so great that it stops conversation cold. Marvin Humphrey - 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: Next steps for various proposals (mentor re-boot, pTLP, etc.)
It doesn't need to be in the public report. I agree the shepherd model doesn't work here but I still maintain that doesn't mean it can't work. Accountability, responsibility and reward are what I believe are needed. I've made my suggestions as to how to provide all three Sent from my Windows Phone From: Marvin Humphreymailto:mar...@rectangular.com Sent: 1/22/2015 11:08 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.) On Thu, Jan 22, 2015 at 4:14 AM, Ted Dunning ted.dunn...@gmail.com wrote: If you would like to characterize shepherds as cross-cutting mentors-at-large, I wouldn't disagree. It's costly to produce such cross-cutting commentary. Because the product ends up in the public report, it's risky to be candid -- recall the Drill shepherd review that raised objections: http://s.apache.org/ed. Shepherds can diminish the risk either by spending more time gathering information, raising the cost, or by being more circumspect, diminishing the review's usefulness. Both choices are suboptimal. In any case, the Incubator struggles to get consistent shepherd participation. While the fact that Incubator shepherds are less accountable than Board members might keep participation under 100% any given month, my guess is that the main reason the number is under 50% and trending downward is cost/benefit ratio -- shepherds are making a rational choice to occupy themselves with tasks they perceive as less arduous and/or more rewarding. Maybe the time will come to revisit this issue if shepherd participation flatlines, though that's not a very satisfying outcome... Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
We should not be focusing on who is/is not ticking a box on a report - it's a red herring and therefore a distraction. We should be focusing on identifying and assisting podlings that are not in receipt of adequate and appropriate mentoring. There is nothing else of importance. Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Marvin Humphrey [mailto:mar...@rectangular.com] Sent: Wednesday, January 21, 2015 2:04 PM To: general@incubator.apache.org Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.) On Mon, Jan 19, 2015 at 2:43 PM, Dave Fisher dave2w...@comcast.net wrote: Perhaps there are one or two good ideas in the proposals, but change does not need to be as jarring. I hope that the Incubator can make the best of those opportunities. For example the IPMC ought to confirm with mentors if they are still being a mentor to a particular podling. There can be many reasons why not and we just need to ask. It could be that the podling never achieved a visible development community. It's possible to automate pinging Mentors who didn't sign off on podling reports. A Python script could parse the last Incubator report (plus others going back N months if we want richer historical info), then send one email per podling to the podling's private list, CC'd to private@incubator. The script could be run by the Report Manager or the Chair each month after the report is filed. Statements like shepherds dilute mentor responsibility are false. A shepherd provides a mechanism for the IPMC to review the Podling/Mentor relationship. This is something the IPMC needs to do when voting to graduate a podling. We should be ALL be doing shepherding work. I can see what Alan's getting at, though. Unless the podling is in trouble, the podling contributors ought to be writing the report. The people who are then best placed to give informed feedback on that report are the podling's Mentors. But instead, the people who provide commentary on the state of the podling community tend to be the shepherds, whose understanding is necessarily more superficial. Doesn't that seem strange? Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
That is not what *I* do as a shepherd. Sent from my Windows Phone From: Marvin Humphreymailto:mar...@rectangular.com Sent: 1/21/2015 7:10 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.) On Wed, Jan 21, 2015 at 3:58 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: We should not be focusing on who is/is not ticking a box on a report - it's a red herring and therefore a distraction. We should be focusing on identifying and assisting podlings that are not in receipt of adequate and appropriate mentoring. Well, the idea is to identify such podlings with as little effort and fanfare as possible. * If a Mentor signs off on a report, trust that they are engaged. * If they don't check the box (for any number of reasons), ping them _privately_ to ask politely whether they're still engaged. I figure that's both more reliable and less intrusive than shepherding. But let's consider retiring the shepherd role and automated private followup after missing signoff as separate initiatives... The first person to do shepherding was Jukka. He couldn't handle the load by himself, so he asked for volunteers[1]. The thing is, the IPMC doesn't seem to have the volunteer capacity to provide senior-level shepherd reviews for all podlings each month, of the kind that a Jukka or a Dave Fisher might write up. And it has always bothered me to have outsiders judging podling communities in the context of a Board report, even when they're experienced. What the Board shepherds do is fundamentally different from what the Incubator shepherds do: Board shepherds trust the report content and follow up after problems, while Incubator shepherds are expected to dive into the mailing list archives and assess community health proactively. To do that right is labor-intensive and basically duplicates work already done by the podling's Mentors. And what are the benefits? * Because shepherd participation is below 50%, we can't count on them to flag problem podlings consistently. * Providing periodic outsider perspectives might be a good thing, but in the context of a Board report, the stakes are too high. * The shepherd gets their mind broadened. This is great, but there are other ways to achieve that. Fortunately, the Incubator has developed better mechanisms identify and track problem podlings. Shepherds were essential while the Incubator was cleaning house in 2012, but that's no longer the case. Therefore, I support Alan's suggestion to simplify the Incubator by streamlining away the shepherd role. The Shepherd/Mentor notes section of the report can be changed to Mentor/IPMC notes. Marvin Humphrey [1] http://markmail.org/message/y3pnb6degtnynmc2 http://s.apache.org/v7g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
My strawman, which included a board like IPMC, certainly wasn't about shutting out inconvenient IPMC members, that is simply a ridiculous a d insulting suggestion (if it wasn't intended in that way then fine, but it sure sounds like it). My strawman was partly about consensus, but mostly about having a group if people who take individual responsibility for doing the unpopular stuff when the process is failing (which is not the norm). Today it is rare for the IPMC to do that stuff, partly because it is hard to gain consensus, but mostly because it has no teeth (a phrase I used a great deal in explaining my strawman). The goal is for that group to prevent the ongoing centralization of the IPMC and put the authority back where it belongs, with active mentors engaged with the project community. I know some people feel that having a smaller group results in greater centralization, but that depends on who is a part of that group. The *only* goal of my strawman was to give the IPMC accountability and teeth. Sent from my Windows Phone From: Bertrand Delacretazmailto:bdelacre...@apache.org Sent: 1/20/2015 6:46 AM To: Incubator Generalmailto:general@incubator.apache.org Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.) On Tue, Jan 20, 2015 at 3:35 PM, Alan D. Cabrera l...@toolazydogs.com wrote: ...Isn’t it obvious what the above and IncubatorV2 proposal are about? Consolidating like minded individuals into a new IPMC and shutting out the other inconvenient members until they come to their senses” I don't buy that conspiracy theory, for me it's just very difficult to build consensus in the Incubator as the goal is much fuzzier than producing software. But maybe I'm too candid ;-) -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: When is an ICLA needed?
I agree with Bertrand. Note whoever commits the patch is doing so under their ICLA. In other words if someone feels it does not contain significant IP then they can commit. Paperwork is a barrier to entry which is simply not necessary for trivial contributions. Sent from my Windows Phone From: Bertrand Delacretazmailto:bdelacre...@apache.org Sent: 1/20/2015 3:39 AM To: Incubator Generalmailto:general@incubator.apache.org Subject: Re: When is an ICLA needed? Hi, On Tue, Jan 20, 2015 at 11:57 AM, Rob Vesse rve...@dotnetrdf.org wrote: ...My understanding was always that the ICLA is only required if you are a committer though may still be desirable for larger contributions,... That's my understanding, requiring an iCLA for minor contributions is not needed. What's important for all contributions IMO is to have documented evidence (dev list, jira, bugzilla) that the contribution is voluntary, and to indicate when committing where the contribution comes from. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Incubating with Apache Commons as champion?
It's not for the IPMC to decide commons policy. If they feel another mailing list is not appropriate that is their call. Sent from my Windows Phone From: Niclas Hedhmanmailto:nic...@hedhman.org Sent: 1/20/2015 8:07 AM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Incubating with Apache Commons as champion? I agree that incoming codebase can go through the IP Clearance, and if the committers are already Commons folks (predominantly), and the only actual issue is the number of mails on the dev@, then I think that separate mailing list is fine, perhaps with the exception of not having a name related to the RDF component, perhaps design-in-progress@ or other indicator that a particular activity is happening there. Niclas On Tue, Jan 20, 2015 at 11:08 PM, Rob Vesse rve...@dotnetrdf.org wrote: Stian If a community made predominantly of existing Apache committers (or containing a strong core of) already exists and this would be a small self contained module as part of Apache Commons then why does the Incubator need be involved at all? Why can this not just be submitted directly to Apache Commons via the IP Clearance procedure (http://incubator.apache.org/ip-clearance/index.html)? Commons already allows any ASF committer to commit so the existing community can continue working on the code just fine. The only sticking point would be once Commons-RDF wants to release in which case you'd likely need to canvas the larger commons community for votes until such time as the Commons-RDF committers have earned sufficient merit to be offered PMC membership On the other hand does Commons-RDF necessarily need to come to the ASF at all? If it is a small self-contained interface module that will remain stable what does it gain (other than brand association) by coming to the ASF? Rob On 20/01/2015 14:28, Stian Soiland-Reyes st...@apache.org wrote: The discussion on dev@commons about coming-to-Apache Commons-RDF (https://github.com/commons-rdf/commons-rdf/) seems to be rejecting a temporary mailing list like rdf@commons as it is seen t be splitting Apache Commons as a project - the ideal committer on Apache Commons is caring about all its components (avoiding the Jakarta pitfalls). We had not considered becoming a TLP as once the API (mainly a set of interfaces) is settled, by then it will probably be pretty much a quiet project except the odd maintenance patch - and also by being a common component of several RDF projects within Apache, its best home then would be under Commons (presumably with most of the original committers still involved). However the large traffic of dev@commons (~400/month) about all the other components can be a problem for trying to engage the non-Apache community around commons-rdf while we flesh out the API. (This has currently been done solely through Github issues, pull requests, and watching the project). In a way we are limited by the technology of the Apache mailing lists. (I know, I know...). (I mentioned gitlab.com ) The suggestion is that Commons-RDF could be a incubator project, but with a projected path to become part of the Apache Commons instead of a TLP. (I believe this path has not happened before) So this would be using the old structure of having a champion of Apache Commons - could this be a workable incubator project? In a way it would be incubating just the code until API maturity rather than the community or Apache Way as both of those already exist. In such an (old skool) setup, would it be the Commons PMC / dev@commons who would vote over the incubating releases? Once graduating it would just become a component under Apache Commons and the community would just be dev@commons where the committers would already be members - the dev@rdf.incubator list would simply close. .. and where would mentors come from? Would existing committers from those other Apache projects (Jena, Marmotta, Clerezza) be enough - or should it be someone from IMPC or from dev@commons? See http://mail-archives.apache.org/mod_mbox/commons-dev/201501.mbox/%3CCAB917 RLJE%2BgFEpw%3Dyp-c-HpXEnvL12JZLLpc4wphGyjGH_6%3D9Q%40mail.gmail.com%3E for the whole threads :) -- Forwarded message -- From: Stian Soiland-Reyes st...@apache.org Date: 20 January 2015 at 14:06 Subject: Re: [DISCUSS][RDF] Separate mailing list for Commons RDF To: Commons Developers List d...@commons.apache.org Agree that maybe the the Incubator with a projected path to the Commons could be a workable middle ground while Commons-RDF is still incubating code-wise (but not community or Apache Way-wise). No earlier project has gone through this route (https://incubator.apache.org/projects/ ) - this would reuse the deprecated Champion project to be Apache Commons instead of Incubator PMC in this case. Such a proposal has some good
RE: Incubating with Apache Commons as champion?
I hear what Stian is saying about the noise in Commons. If the team feel its not going to work for them then the incubator might be the right route. IMHO there is no reason why you couldn't be sponsored by the commons PMC. You would still need the IPMC to clear releases but that means three IPMC +1 votes. I'm not sure when this became a requirement for an IPMC vote. It used to be that the IPMC was notified. I always ensured that the mentors all voted first (incidentally this is a good check point to see if mentors are still active). ASIDE: I strongly recommend a return to the original notification of a VOTE in progress. This is another example of unnecessary centralization of process in the IPMC. Control should be with the podlings and its mentors, oversight should be with the PMC. If anyone wants to respond to this make it a new thread please. Let's not distract from this conversation. I see no reason why your project can't come here, and can graduate to commons if that is what is desired. Ensure you have enough mentors (must be IPMC members, which means ASF members although I can think of a few people on RDF projects I would be happy to vote onto the IPMC if necessary) to get 3 +1 release votes and ensure they are strong enough to tell the IPMC to get out of the way (when appropriate). Ross Sent from my Windows Phone From: Rob Vessemailto:rve...@dotnetrdf.org Sent: 1/20/2015 7:10 AM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Incubating with Apache Commons as champion? Stian If a community made predominantly of existing Apache committers (or containing a strong core of) already exists and this would be a small self contained module as part of Apache Commons then why does the Incubator need be involved at all? Why can this not just be submitted directly to Apache Commons via the IP Clearance procedure (http://incubator.apache.org/ip-clearance/index.html)? Commons already allows any ASF committer to commit so the existing community can continue working on the code just fine. The only sticking point would be once Commons-RDF wants to release in which case you'd likely need to canvas the larger commons community for votes until such time as the Commons-RDF committers have earned sufficient merit to be offered PMC membership On the other hand does Commons-RDF necessarily need to come to the ASF at all? If it is a small self-contained interface module that will remain stable what does it gain (other than brand association) by coming to the ASF? Rob On 20/01/2015 14:28, Stian Soiland-Reyes st...@apache.org wrote: The discussion on dev@commons about coming-to-Apache Commons-RDF (https://github.com/commons-rdf/commons-rdf/) seems to be rejecting a temporary mailing list like rdf@commons as it is seen t be splitting Apache Commons as a project - the ideal committer on Apache Commons is caring about all its components (avoiding the Jakarta pitfalls). We had not considered becoming a TLP as once the API (mainly a set of interfaces) is settled, by then it will probably be pretty much a quiet project except the odd maintenance patch - and also by being a common component of several RDF projects within Apache, its best home then would be under Commons (presumably with most of the original committers still involved). However the large traffic of dev@commons (~400/month) about all the other components can be a problem for trying to engage the non-Apache community around commons-rdf while we flesh out the API. (This has currently been done solely through Github issues, pull requests, and watching the project). In a way we are limited by the technology of the Apache mailing lists. (I know, I know...). (I mentioned gitlab.com ) The suggestion is that Commons-RDF could be a incubator project, but with a projected path to become part of the Apache Commons instead of a TLP. (I believe this path has not happened before) So this would be using the old structure of having a champion of Apache Commons - could this be a workable incubator project? In a way it would be incubating just the code until API maturity rather than the community or Apache Way as both of those already exist. In such an (old skool) setup, would it be the Commons PMC / dev@commons who would vote over the incubating releases? Once graduating it would just become a component under Apache Commons and the community would just be dev@commons where the committers would already be members - the dev@rdf.incubator list would simply close. .. and where would mentors come from? Would existing committers from those other Apache projects (Jena, Marmotta, Clerezza) be enough - or should it be someone from IMPC or from dev@commons? See http://mail-archives.apache.org/mod_mbox/commons-dev/201501.mbox/%3CCAB917 RLJE%2BgFEpw%3Dyp-c-HpXEnvL12JZLLpc4wphGyjGH_6%3D9Q%40mail.gmail.com%3E for the whole threads :) -- Forwarded message -- From:
RE: When is an ICLA needed?
Benson is correct: Section 4 of the ICLA states You represent that you are legally entitled to grant the above license. It doesn't say you own copyright, only that you have the permission to grant the license on the copyrighted material (which the copyright owners indicates by making the patch available in JIRA, the pull request on GitHub or whatever process the project uses). As for the original author being shown that is culturally important (merit) and legally important (traceability). The committer is also recorded. Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: John D. Ament [mailto:johndam...@apache.org] Sent: Tuesday, January 20, 2015 10:56 AM To: general@incubator.apache.org Subject: Re: When is an ICLA needed? On Tue Jan 20 2015 at 1:54:32 PM Benson Margulies bimargul...@gmail.com wrote: On Tue, Jan 20, 2015 at 1:40 PM, Branko Čibej br...@apache.org wrote: On 20.01.2015 17:16, Ross Gardler (MS OPEN TECH) wrote: I agree with Bertrand. Note whoever commits the patch is doing so under their ICLA. Really? That can't be right: one can't become the author of a change (and therefore can't license it to the ASF) merely by having committed it. That's why we require an audit trail to the original author, right? It has to be 'right', but you're reading too much into Ross' remark. When you signed the ICLA, you agreed to abide by its terms. That doesn't make you the author of everything you commit. No, but it makes it odd when you start merging github pull requests. The original author is the one shown. John In other words if someone feels it does not contain significant IP then they can commit. Paperwork is a barrier to entry which is simply not necessary for trivial contributions. That's a different matter, and I agree. -- 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: Next steps for various proposals (mentor re-boot, pTLP, etc.)
As an IPMC member I have objected to this part of the report. As a Director I have already commented on the report that this practice is inappropriate. I will ask for that section to be struck from the minutes, we'll see if other directors agree. My comment on the report is: rg: I've already made the point on the incubator list but I do not see benefit in highlighting mentors who have not signed-off. It means very little in isolation (a busy volunteer who didn't have the time to tick a box on a wiki is not necessarily an absent mentor from the project community). Given these records are public I would prefer not to see this data in the minutes. Ross -Original Message- From: Andrew Purtell [mailto:apurt...@apache.org] Sent: Tuesday, January 20, 2015 11:18 AM To: general@incubator.apache.org Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.) I just experienced being placed on a naughty list in the last incubator report because I was travelling for business and missed checking the box for HTrace. It may not be on any specific proposal. It seems to already be in practice. On Tue, Jan 20, 2015 at 6:36 AM, Alan D. Cabrera l...@toolazydogs.com wrote: Can you add your concerns to the end each of the wiki pages? I intend to update my proposal to clear up the apprehensions that you seem to have. You can then remove/amend your concerns from the wiki proposal. I will quickly state that “naughty lists” are not part of the mentor-reboot proposal. Thanks! Regards, Alan On Jan 19, 2015, at 3:55 PM, Andrew Purtell apurt...@apache.org wrote: I think the cures are all problematic and might be worse than the disease. On Mon, Jan 19, 2015 at 1:47 PM, Roman Shaposhnik r...@apache.org mailto:r...@apache.org wrote: On Wed, Jan 14, 2015 at 8:48 AM, Roman Shaposhnik r...@apache.org wrote: Hi! at this point we have had a few lively threads discussing three somewhat different proposals: #1 mentor re-boot #2 pTLP #3 Ross's strawman http://s.apache.org/8eS it feels to me that all three need additional work to be done before we can have any reasonable consensus around them (let alone voting). Wearing my chair hat, I would like to suggest that the next step should be: for each proposal we identify points that are going to block consensus (AKA would result in -1 vote if it comes to a vote). I suggest we do it on the wiki pages themselves (I'll wikify Ross's proposal tonight). Not editing the wikis but simply collecting this feedback as the last section in each proposal. The idea would be to identify all such points in a week or so. Sounds good? To follow up. Each of the proposals: https://wiki.apache.org/incubator/MentorRebootProposal An active mentor is removed from a podling if that mentor does not review/sign off on a release. The above implies the foundation has a pool of mentors able to consistently meet every reporting requirement in a timely manner, without regard to personal or professional obstacles. I don't see it. For an organization almost entirely made up of volunteers this seems overly optimistic. There is only a small core membership who are capable and willing to do this as evidenced by a skim of history of general@incubator and members@. Perhaps this core group will end up shouldering the incubation load in its entirety. Although sadly this is more or less the current state of affairs, individual podlings do come with new mentors not part of the professional membership motivated to see at least that specific podling through. It's also risky to expect mentors kicked from a podling to be okay with it and want to try again, especially if listed on some naughty list to the board. https://wiki.apache.org/incubator/Strawman https://wiki.apache.org/incubator/Strawman Only ASF members on the PPMC will have binding votes for the releases. This proposal seems better than the others in my estimation, but doesn't allow podlings full investment in their own release management. The members on the PPMC who have binding votes will drive the release process out of necessity. Once the podling graduates and the members on the PPMC leave to resume other interests or duties, only then for the first time is the project running their own releases. I think it was better to let the podling own their release process but have the IPMC (or equivalent) have an up-or-down vote afterward as a check on their activities. https://wiki.apache.org/incubator/IncubatorV2 https://wiki.apache.org/incubator/IncubatorV2 This proposal revokes merit earned by existing IPMC members and reboots incubator supervision as a sub-board limited to 15 members. How members apply to this board is not specified. It is suggested the current board make recommendations to
RE: Is there a place I can programmatically pull in PPMC members?
Sorry misread your request as IPMC Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Alan D. Cabrera [mailto:a...@toolazydogs.com] Sent: Tuesday, January 20, 2015 11:17 AM To: infrastructure-...@apache.org Cc: general@incubator.apache.org Subject: Re: Is there a place I can programmatically pull in PPMC members? This seems to get me the IPMC members, not the PPMC members of podlings. Am I misinterpreting the page? Regards, Alan On Jan 20, 2015, at 11:04 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: See the code behind Whimsy (https://whimsy.apache.org/technology.html) The part you looking for produces https://whimsy.apache.org/roster/committee/incubator Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Alan D. Cabrera [mailto:l...@toolazydogs.com] Sent: Tuesday, January 20, 2015 10:58 AM To: infrastructure-...@apache.org; general@incubator.apache.org Subject: Is there a place I can programmatically pull in PPMC members? Is there a place I can programmatically pull in PPMC members? Regards, Alan - 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
Reporting and releasing for Ripple
The Ripple community asked for a stay of execution before being moved to the attic, as was recommended by some. This was granted in November 2014 with a review in six months. No board report was submitted this month and no action has been taken with respect to the concerns I raised about releases from this project. If this project community wishes to continue to operate as an incubating project, and eventually graduate, then these items need to be addressed. There are two months remaining. Without an ASF approved release happening in that period it is unlikely that the IPMC will approve a further six months. I'm here as a mentor and ready to help guide any member of this community (committer or otherwise, everyone is welcome) in making a release. Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation
RE: What is The Apache Way?
The archive is the mailing list archives and issue trackers. If an authoritative answer is required then we have VPs who are empowered to make operational decisions relating to policy and a Board empowered to make community decisions (and oversee the operational side). As you say, we try not to have a top down approach, but sometimes it is necessary. Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Alex Harui [mailto:aha...@adobe.com] Sent: Friday, January 16, 2015 9:12 AM To: general@incubator.apache.org Subject: Re: What is The Apache Way? On 1/16/15, 6:10 AM, Rich Bowen rbo...@rcbowen.com wrote: Yes, with all of my various hats, I heartily endorse this task. You're right, this would be of great value both inside and outside of Apache. I’m definitely eager to see what Marvin can do here. I’ve been wondering though: any top-level policy document cannot fully specify all human behavior. IMO, that’s why governing bodies have authority figures who make judgement calls. The US has a judicial system, the game of golf has a group of folks who make decisions. Is it the various VP’s that get to be the judge? I’ve often thought about golf when following Apache policy threads. Golf has a reasonably detailed rule book but they realize that there are lots of edge cases in real life and the rule book would be unwieldy if it tried to specify everything. So the rule book tries to carefully specify general principles and is rarely changed. Then there is a whole archive of decisions associated with each rule where this group of folks records decisions made. Is it reasonable to do something like this at Apache? Apache Legal seems to already have something like this. There are legal policy docs, then the legal-resolved page. One of the questions I often have when using legal-discuss is whether the answer I’m getting is authoritative or not. I know folks are leery about establishing a tier of folks who can authoritatively make the judgement calls, but maybe we have to have that so that folks know when they are getting an official answer vs the opinions of other community members. To become a golf rules official you have to pass a test. And to get on the board of official golf decision makers is a much harder task. Maybe we need a test in order to be an Apache Way Rules Official. -Alex - 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: Next steps for various proposals (mentor re-boot, pTLP, etc.)
http://wiki.apache.org/incubator/IncubatorIssues2013 Ross -Original Message- From: Alan D. Cabrera [mailto:l...@toolazydogs.com] Sent: Friday, January 16, 2015 3:13 PM To: general@incubator.apache.org Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.) On Jan 16, 2015, at 3:04 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Or we could just do it We debated plenty. Three proposals came out of it (two if you look at mine as the strawman it was intended to be). Those proposals are not mutually exclusive. I say record them in the wiki. Run them for a while. Then compare against the problems document we drew up a couple of years back and see how effective they are. Where is this problems document? Regards, Alan - 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?
That's already in progress as part of this year's budget planning :-) Of course this is distinct from policy. For example: Should the policy say projects are limited to items on the infra core services list? Ross Sent from my Windows Phone From: Shane Curcurumailto:a...@shanecurcuru.org Sent: 1/15/2015 4:55 PM To: Marvin Humphreymailto:mar...@rectangular.com; general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: What is The Apache Way? Dear David: I would *love* to see you propose whatever set of requirements that ASF infra as a service sees as appropriate for our projects, given our history, budget, and a view to ensuring reliable service for the future. Then, include a clear list of bullet points which should go into the Project Requirements document. Then president@/board@ can decide what to officially stamp as hard policy vs. recommended suggestions, put them in Project Requirements, and take the *DRAFT* off. But everything happens better when there's a concrete plan up front, and I'm confident your infra team will come up with the right requirements as relates to infra for projects. - Shane On 1/15/15 6:51 PM, Marvin Humphrey wrote: On Tue, Jan 13, 2015 at 9:37 AM, David Nalley da...@gnsa.us wrote: My assumption was that 'setting binding policy on projects' was something specifically excluded from my level of authority, as an officer derived from the Office of the President. If that is not the case, I am happy to define and publish such things within the realm of infrastructure. Hi David, Since it's seems that you're willing and we have good rapport, I think it might work well to kick things off with Infra. Here's my provisional agenda: 1. Hash out DRAFT policies with Infra. 2. Work with Legal Affairs to complete the release policy codification initiative. 3. Review the top level Project Requirements document. 4. ... I'm presently contemplating that Infrastructure would curate two policies: * Infrastructure Policy * Release Distribution Policy Infrastructure Policy would cover topics such as canonical repository location and usage of external services, as you and Doug discussed upthread. Release Distribution Policy would cover technical details of releasing, such as cryptographic signature specs, responsibility for keeping dist dirs tidy, and so on. These aspects are covered (incompletely) in the present Releases Policy (http://www.apache.org/dev/release), but are omitted from the clarified release policy which Legal Affairs is being asked to take ownership of (https://github.com/rectang/asfrelease) because they are outside Legal's domain. If that sounds workable, let me mull things over for a bit, then I plan to show up on infrastructure-dev@apache with some sketches. The content is ultimately your call and I don't expect to get all the details right, but before discussions commence in earnest, I'd like to mess around with language and high-level organization to seek out approaches that are as minimalist and flexible as possible. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Final draft of IPMC report for January 2015
What does it mean to didn't sign-off does it mean they refused to sign-off or that they simply didn't tick a box? Does it mean they didn't even read the report or that they didn't tick a box? I've said it before, I see no value in having a naughty list like this. What I care about (with my Director hat on) is whether the mentors are engaged with the project. If the IPMC wants to maintain a didn't sign off list for some internal management reasons that's fine. But putting it in the public minutes of the foundation is a completely different thing altogether (in fact it is already there, it's just that individuals names are not singled out like this). When the data is incorrect as this thread shows it's even more of an issue. Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Daniel Gruno [mailto:humbed...@apache.org] Sent: Wednesday, January 14, 2015 8:48 AM To: general@incubator.apache.org Subject: Re: Final draft of IPMC report for January 2015 *ahem*, I did sign off on both reports. However, my wiki access was fubared at the time, so I asked if anyone from the Ranger project could put a check mark next to my name. This has apparently not happened. I have also signed off on the Corinthia report. With regards, Daniel. On 2015-01-14 17:42, Roman Shaposhnik wrote: The following will be submitted to the board at midnight: The Apache Incubator is the entry path into the ASF for projects and codebases wishing to become part of the Foundation's efforts. There are currently 36 podlings undergoing incubation. One podling joined us this month (Corinthia). One member joined and two members left the IPMC. IPMC has recognized the need for tightening up mentorship requirements and overall structure of the incubation process. Active discussions on how to this in the best possible way are on going and the recommendation is expected to be available in a few weeks. * Community New IPMC members: Hyunsik Choi People who left the IPMC: Sean Owen Marvin Humphrey Mentors who didn't sign off on the reports: Alan Gates Alex Karasulu Andrei Savu Andrew Purtell Arun Murthy Ashutosh Chauhan Benjamin Hindman Daniel Gruno David Blevins Devaraj Das Drew Farris Enis Soztutar Gerhard Petracek Henri Gomez Henry Saputra Lewis John Mcgibbney Luciano Resende Marcel Offermans Matt Hogstrom Nick Burch Olivier Lamy Sam Ruby Sergio Fernandez Suresh Marru Suresh Srinivas Todd Lipcon Tom White Yegor Kozlov * New Podlings Corinthia * Graduations The board has motions for the following: Samza * Releases The following releases were made since the last Incubator report: Dec 05 2014 Apache Falcon 0.6-incubating Dec 08 2014 Apache Samza 0.8.0-incubating Dec 22 2014 Apache Brooklyn 0.7.0-M2-incubating * IP Clearance * Corinthia initial source grant * Legal / Trademarks * Infrastructure * Miscellaneous * NPanday community seems to be in agreement that retirement is the best option at this point. The only outstanding issue before formally recommending graduation VOTE is to decide whether there's enough cycles available for one last release before retirement. Summary of podling reports * Still getting started at the Incubator SAMOA Corinthia Kylin NiFi Taverna (delayed software grant) Zeppelin * Not yet ready to graduate No release: DataFu HTrace Ignite Kalumet Lens Tamaya Community growth: Aurora Brooklyn Calcite MRQL ODF Toolkit Parquet Ranger Usergrid * Ready to graduate The Board has motions for the following: Samza * Did not report, expected next month NPanday Ripple -- Table of Contents Aurora Brooklyn Calcite Corinthia DataFu HTrace Ignite Kalumet Kylin Lens MRQL NiFi NPanday ODF Toolkit Parquet Ranger SAMOA Samza Tamaya Taverna Usergrid Zeppelin -- Aurora Aurora is a service scheduler used to schedule jobs onto Apache Mesos. Aurora has been incubating since 2013-10-01. Three most important issues to address in the move towards graduation: 1. Expanding the community's diversity and adding new committers. 2. Third Apache release, progress being tracked in ticket AURORA-872 3. Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be aware of? * None at this time. How has the community developed since the last report?
RE: Final draft of IPMC report for January 2015
I don't agree with many of the assertions below. But I'll not easy those arguments My concern is this going into public record without an adequate explanation of what it means. You addressed that - thank you. Sent from my Windows Phone From: Alan D. Cabreramailto:l...@toolazydogs.com Sent: 1/14/2015 11:38 AM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Final draft of IPMC report for January 2015 On Jan 14, 2015, at 10:56 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: What does it mean to didn't sign-off does it mean they refused to sign-off or that they simply didn't tick a box? Does it mean they didn't even read the report or that they didn't tick a box? I've said it before, I see no value in having a naughty list like this. What I care about (with my Director hat on) is whether the mentors are engaged with the project. If the IPMC wants to maintain a didn't sign off list for some internal management reasons that's fine. But putting it in the public minutes of the foundation is a completely different thing altogether (in fact it is already there, it's just that individuals names are not singled out like this). When the data is incorrect as this thread shows it's even more of an issue. TL;DR naughty list” metrics are useful and the various scenarios listed above are “red herrings”. General and podling specific “opaque metrics on mentor sign-off are just as useful and more easily digested. Mentors who refuse to sign-off are obviously engaged and would update the report to reflect their refusal and, likely, reasons for not signing as this would be a very notable event. I trust Roman to not include those mentors in the naughty list”. Tooling issues aside. (If anything, the list has caused naughty list” mentors to make sure the report is accurate. Frankly, I would never rescan the final report for my podlings otherwise.) I think that it’s reasonable to expect that if a mentor read a report then they would have ticked the box. Finally, it is a useful metric that provides some visibility into the amount of oversight that’s taking place. Sure, it’s a metric and does not provide total transparency and understanding but it is useful never the less. With that said, I do agree that a board report is not the appropriate venue for the Weegee paddy wagon parade. What would be more useful and more easily digested is a general top level opaque metric, e.g. 55% of the mentors signed off on reports, and then for each podling a similar metric. Anyone interested in catching me in my best herringbone wool skirt can inspect the report at individual podling level. Regards, Alan
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Thank you for volunteering to wikify my proposal - I appreciate it. 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: Wednesday, January 14, 2015 8:48 AM To: general@incubator.apache.org Subject: Next steps for various proposals (mentor re-boot, pTLP, etc.) Hi! at this point we have had a few lively threads discussing three somewhat different proposals: #1 mentor re-boot #2 pTLP #3 Ross's strawman http://s.apache.org/8eS it feels to me that all three need additional work to be done before we can have any reasonable consensus around them (let alone voting). Wearing my chair hat, I would like to suggest that the next step should be: for each proposal we identify points that are going to block consensus (AKA would result in -1 vote if it comes to a vote). I suggest we do it on the wiki pages themselves (I'll wikify Ross's proposal tonight). Not editing the wikis but simply collecting this feedback as the last section in each proposal. The idea would be to identify all such points in a week or so. Sounds good? Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Please go ahead - apologies for not doing it myself I have access problems on the incubator wiki. Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: John D. Ament [mailto:johndam...@apache.org] Sent: Wednesday, January 14, 2015 9:22 AM To: general@incubator.apache.org Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.) Anyone mind then if i put strawman up on the wiki? On Wed Jan 14 2015 at 12:11:42 PM Alan D. Cabrera l...@toolazydogs.com wrote: On Jan 14, 2015, at 8:48 AM, Roman Shaposhnik r...@apache.org wrote: Hi! at this point we have had a few lively threads discussing three somewhat different proposals: #1 mentor re-boot https://wiki.apache.org/incubator/MentorRebootProposal https://wiki.apache.org/incubator/MentorRebootProposal #2 pTLP http://wiki.apache.org/incubator/IncubatorV2 http://wiki.apache.org/ incubator/IncubatorV2 #3 Ross's strawman http://s.apache.org/8eS it feels to me that all three need additional work to be done before we can have any reasonable consensus around them (let alone voting). Wearing my chair hat, I would like to suggest that the next step should be: for each proposal we identify points that are going to block consensus (AKA would result in -1 vote if it comes to a vote). I suggest we do it on the wiki pages themselves (I'll wikify Ross's proposal tonight). Not editing the wikis but simply collecting this feedback as the last section in each proposal. The idea would be to identify all such points in a week or so. Sounds good? Thanks for picking this up. Does it make sense to make a matrix to compare them? I’m happy to take a crack at it. Could you field offline questions about #2 for me? Regards, Alan
RE: What is The Apache Way?
Good suggestion. Sent from my Windows Phone From: Jim Jagielskimailto:j...@jagunet.com Sent: 1/13/2015 9:33 AM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: What is The Apache Way? Perhaps it is time we hired a contractor to draw up the one document of truth? My thoughts are that Sally certainly groks the Apache Way, and knows who to contact for more detailed info and clarification. Why not add this as a task to HALO, and put some $$$ towards it? - 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?
Even better suggestion. Do you want to take it up with Sally directly? (and big thanks in advance) Sent from my Windows Phone From: Jim Jagielskimailto:j...@jagunet.com Sent: 1/13/2015 9:33 AM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: What is The Apache Way? If we go that route, I'll own it, since it makes sense as a VP Legal responsibility in a lot of ways. On Jan 13, 2015, at 12:29 PM, Jim Jagielski j...@jagunet.com wrote: Perhaps it is time we hired a contractor to draw up the one document of truth? My thoughts are that Sally certainly groks the Apache Way, and knows who to contact for more detailed info and clarification. Why not add this as a task to HALO, and put some $$$ towards it? - 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?
Thanks for taking my comment the way it was intended (to fuel productive debate) :-) You are right that VPs don't set policy but they should write policy and submit to the board for tuning and/or approval/rejection. In turn those VPs will typically consult with their committee members. It really should be bottom up. This scales well. Looking to a board of 9 overworked directors to do everything for 150+ projects (and potentially adding podlings based on some IPMC recommendations) does not scale. That being said, you are correct the release policy is really a legal issue and thus is under VP Legal, with VP Infra needing to approve any policy since it has impact on what infra needs to deliver. Fortunately Jim has indicated he feels he owns much of this as VP Legal so you are off the hook and made your point well - a good result for you I think :-) Here's to Jim for stepping up and offering to try to heard the sheep on this one. Ross -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Tuesday, January 13, 2015 9:37 AM To: general@incubator.apache.org Subject: Re: What is The Apache Way? On Tue, Jan 13, 2015 at 11:23 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Well, David, I'm afraid you are the authoritative source on the policy you use as an example. :) Well - I suppose I did open myself up for that. If it's not documented and that's a problem then it's *your* problem. You could (given even more time to volunteer to the ASF, solve it however you like (e.g. Write the doc, ask the community to write it, ask for budget to have a contract write it, something else), but it's you and the infra team that own this. So, infra has a number of policies - like not keeping more than the current release on dist, giving us a heads up if your artifacts are going to be more 1GB, but they are largely centered around efficient operation of infrastructure, and not Apache Doctrine. Defining (and by extension enforcing) Apache Doctrine, means that infrastructure becomes the Foundation's policeman, at least in certain matters. Infrastructure, derives authority from the office of the President. Based on my reading of the bylaws, and the almost recent discussion around Brand issues - I walked away with the fact that the office of the President may not be able to set binding policy on projects. (differentiated from binding policy of how you may use resources of the Foundation). In the specific example I referenced - which came up in May (on board-private because there was a security issue related to it) I was told to carry the issue to the public board mailing list after the security issue was dealt with because it needed discussing. It did get discussed - release policy (which I think was later declared to be a legal issue), which is a board committee. After that thread revealed that there was no written policy, I explicitly asked several directors (individually) if that was within my scope to define, so as to remove the ambiguity and walked away with the impression that most of them felt it was not within my level of authority. I hope you won't take this personally, its not meant that way. As a volunteer you do a fantastic job and we are all immensely grateful. However, you did feed me a perfect way to illustrate the point I've been trying to make when highlighting docs and saying patches welcome. Not at all. My assumption was that 'setting binding policy on projects' was something specifically excluded from my level of authority, as an officer derived from the Office of the President. If that is not the case, I am happy to define and publish such things within the realm of infrastructure. Perhaps it is time we hired a contractor to draw up the one document of truth? I'm working on the 2015 budget now. Any volunteers to own this? Ownership is ensuring that the individual gets access to all the appropriate VPs and that those VPs are able to provide the necessary input. I think Marvin could manage this well (yes, this is me pushing you in front of the bus, Marvin. My apologies). Failing that, I'm happy to tackle management of that. --David - 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: What is The Apache Way?
Well, David, I'm afraid you are the authoritative source on the policy you use as an example. If it's not documented and that's a problem then it's *your* problem. You could (given even more time to volunteer to the ASF, solve it however you like (e.g. Write the doc, ask the community to write it, ask for budget to have a contract write it, something else), but it's you and the infra team that own this. I hope you won't take this personally, its not meant that way. As a volunteer you do a fantastic job and we are all immensely grateful. However, you did feed me a perfect way to illustrate the point I've been trying to make when highlighting docs and saying patches welcome. Perhaps it is time we hired a contractor to draw up the one document of truth? I'm working on the 2015 budget now. Any volunteers to own this? Ownership is ensuring that the individual gets access to all the appropriate VPs and that those VPs are able to provide the necessary input. Sent from my Windows Phone From: David Nalleymailto:da...@gnsa.us Sent: 1/13/2015 7:45 AM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: What is The Apache Way? On Mon, Jan 12, 2015 at 12:55 PM, Doug Cutting cutt...@apache.org wrote: On Sun, Jan 11, 2015 at 9:49 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: I think a better analogy would be US Culture. Yes it is as nebulous as it gets, but the fact that US Constitution exists as a written document makes a LOT of things WAY easier. Apache's constitution is the corporate bylaws: http://www.apache.org/foundation/bylaws.html US Culture is stuff like Starbucks, Elvis, Manifest Destiny, etc. Most of that is not coded as law, thankfully. Except that there generally aren't authority figures to whom I am answerable to telling me I am doing it wrong if I don't drink Pumpkin Spice Latte's while listening to Blue Suede Shoes. Going back to a conversation from the middle of last year as an example, there is no documented expectation (unless you consider Shane's recently created page authoritative) that the canonical source code repository must live on ASF hardware. Which is fine, we all know the reason why, but when newcomers show up, they don't, and it seems like we are a mass of unwritten rules that MUST be followed. --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?
Marvin, it doesn't need assigning. Just step up and do it. There may not be full consensus on the value of this, but I think there are enough people saying it has value to mean that it has some value. Note the overlapping mails from Jim. I think it makes a huge amount of sense to have budget to deliver the words on a page (as opposed to doing the hard work of building consensus on what needs to be said by those words). That being said if you can deliver without budget to support the effort that's all the better. Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] Sent: Tuesday, January 13, 2015 12:59 PM To: general@incubator.apache.org Subject: Re: What is The Apache Way? On Tuesday, January 13, 2015, Marvin Humphrey mar...@rectangular.com wrote: ...If the Board is willing to commission such a document, I will make it happen That would be fantastic, I think you'd do a great job in coordinating this effort. As you say I do care a lot about those things, but I often lack the continuous attention that's needed to finalize the set of document that we need. If you're willing to take on this coordination and leadership effort (on comdev I guess) you have my big +1. -Bertrand - 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: What is The Apache Way?
So I link to a document and say it contains the list of immutable items, acknowledge it is merely a signpost, and request contributions. Your response that's not good enough, h Marvin you undertook to do the release requirements doc. You did huge amounts of work on it. All that is needed is to make it official. You do that back getting VP Legal to approve it. VP Legal might ask the board for input, but he doesn't need to. He has the authority to just approve it. There can be no dissenting voices, he is the deadlock breaker. If the membership don't like the decision they petition the board to remove him. If the board don't do so the membership calls a members meeting to replace the board. Like I said elsethread there is no hierarchy here unless a big stick is needed. But don't expect the one with the stick to wield it without there being an identified need. That would be overstepping the cultural objective of no leaders. I use your work only as an example. I'm not picking on you, I'm actually acknowledging your contribution to the intended process - thank you. Maybe someone will finalize the doc and ask VP Legal to approve it. Sent from my Windows Phone From: Marvin Humphreymailto:mar...@rectangular.com Sent: 1/10/2015 12:05 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: What is The Apache Way? On Fri, Jan 9, 2015 at 12:01 PM, Rich Bowen rbo...@rcbowen.com wrote: On 01/09/2015 02:03 PM, Jim Jagielski wrote: Another way to look at the Apache Way is as a musical composition. Sure, it was written for a specific arrangement, but sometimes it's played as a jazz piece, other-times as a classical, or maybe with a blues flavor. But it is always (or*should be*) recognizable. If you*don't* recognize it, then you've taken the interpretation too far, if you get my meaning. What a delightful analogy. Of course, you're always going to get people who say that a disco rendition is fine, and others who say it's blasphemous. From my perspective, that explanation of The Apache Way was fine, but completely unhelpful. Similarly, a signpost document collecting links is no more useful in establishing the boundaries of Apache's project requirements than countless other incomplete, unofficial resources. The willingness of a Board member or other authority to provide answers to specific questions is marginally helpful -- until contradictory answers are provided by a competing authority. Somewhere out there in the vast wasteland of Apache's websites and mailing list archives, there exist requirements that Apache projects *must* fulfill or face sanction by the Board. Theoretically there are not many absolute requirements, but learning all of them is literally impossible: there is no authoritative document setting limits on what Apache expects of its projects. Determining what you can get away with at Apache entails digging through huge scrap heaps of documentation and picking the brains of various unreliable oracles. It's maddeningly laborious and slow, and ultimately you can never have much confidence in the answers you unearth. I don't place much value on giving the Board so much flexibility. My sympathies lie with the poor slobs trying to figure out where Apache's rules begin and end -- and with those who build strong communities according to their own good faith interpretation of The Apache Way, only to face censure because their interpretation turned out to be wrong. Maintaining the Board's flexibility to pass judgment while denying those it oversees the rule of law is a poor tradeoff. It is incredibly inefficient, and it makes the Incubator's mission untenable. Even if the Board makes good calls every once in a while, the rest of us should not have to live in perpetual uncertainty. Marvin Humphrey - 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?
+1, I'll repeat one a little my previous mail and say patches welcome (as long as they keep the document simple - remember, it's a signpost document not a discussion or detail document - the discussion/detail documents should be linked from this one). 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). Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Doug Cutting [mailto:cutt...@apache.org] Sent: Friday, January 9, 2015 9:05 AM To: general@incubator.apache.org Subject: Re: What is The Apache Way? On Fri, Jan 9, 2015 at 8:12 AM, Benson Margulies bimargul...@gmail.com wrote: So, either a lot of us are really stupid, or the Foundation as a whole has a gap between the general principles and their application. No, we can't have a rule book that details every particle of how to run an Apache project, but apparently we could have more concrete guidance. The gap definitely exists. What often leads to confusion is when folks think there's no gap, that everything is clear-cut and certain, when it's not. Different Apache projects are permitted to operate differently, and the ill-defined line of what's acceptable moves over time. This is not entirely bad. Fixed practices are hard to change, but the open-source software world changes rapidly. So maintaining some flexibility is important. What we should try to do are document acceptable practices, those ways of operating that are common in many projects and have worked well. There may be multiple acceptable practices in a given area (e.g., CTR RTC). Projects that diverge from these might still be acceptable, but they might also run into problems and should proceed with caution. Some might tell them that they don't get the Apache Way, which is distressing, but, at the end of the day, so long as the board doesn't vote to evict them from the foundation, they're part of the Apache Way. The board doesn't generally act without good notice. Generally things escalate from folks griping, to the board agreeing to monitor and advise a project, to the board giving an ultimatum for a specific practice to stop, to the board finally taking some action. Doug - 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: 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: 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: 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
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?
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
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
RE: Incubator report sign-off
As I've said repeatedly. This simply moves the problem it does not solve it. Today, a project has mentors, usually it works, but sometimes it doesn't. When it doesn't work someone needs to fix it. That is the work that is being moved from the IPMC to the board by the pTLP proposal. It's not necessarily a bad thing and may be acceptable to the board, but I don't understand why proponents of this approach feel it is a solution rather than a moving of the problem. Furthermore, I've not even started on who would own the documentation aspect (yes the proposal is ComDev but just as last time this was circulated nobody has asked ComDev if they are willing to take it on and nobody has turned up in ComDev to do the work. This proposal is not necessarily flawed, but it is incomplete. Ross -Original Message- From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman Shaposhnik Sent: Monday, January 5, 2015 1:52 PM To: general@incubator.apache.org Subject: Re: Incubator report sign-off On Mon, Jan 5, 2015 at 1:07 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: But the board is not responsible for any actions resulting from those reviews, the IPMC is. Agreed for the state of the things today. What is being proposed is that actions resulting from those reviews are going to be pTLPs PMC responsibility. Since in the new world order each pTLP PMC is guaranteed to have 3 ASF members and a chair (one of the 3) that is also an ASF member, I don't think I can see how this would be disagreeable with the mechanics of ASF board. 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
Note from the board - from an IPMC member (and yes, my opinions don't change if I put my Director hat on but don't assume that I speak for all board members) 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: Monday, January 5, 2015 3:39 PM To: general@incubator.apache.org; Benson Margulies Subject: Re: Incubator report sign-off I am clearly hitting my rate-limit with emails to general@, still since Ross' reply was one of the few pieces of feedback from the board, I'll do this one and then wait for others to chime in (Benson?). On Mon, Jan 5, 2015 at 2:27 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: This proposal is not necessarily flawed, but it is incomplete. Couldn't agree more. But! The whole point is to try our best to get this: https://wiki.apache.org/incubator/IncubatorV2 to completion. Your direct feedback (as a sort of proxy for the board) is *very* much appreciated. As I've said repeatedly. This simply moves the problem it does not solve it. Today, a project has mentors, usually it works, but sometimes it doesn't. When it doesn't work someone needs to fix it. That is the work that is being moved from the IPMC to the board by the pTLP proposal. Benson, perhaps we need to create an FAQ around failure scenarios on your wiki page. Here's what I would say to address the failure scenario described by Ross. 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. So lets, break the cases down: 1. pTLP is *really* doing fine, which means: 1.1. overseeing committee has nothing to address 1.2. board *still* has to review the reports (as it does today) and agrees with the overseeing committee END RESULT: no additional work for the board 2. pTLP is NOT doing fine, but it doesn't gets flagged by the committee: 2.1. board expresses its concerns *directly* to the pTLP PMC while CCing the committee essentially pointing out something that fell through the cracks when it should NOT have. NOTE: a huge difference here is that board does NOT expect a committee to fix the issue, but rather makes it aware of something that should've been flagged by it. Only pTLP PMC can act to remedy the issue, nobody else can help them (they could, of course, request help, but again -- it has to come from them 2.2. pTLP PMC either fixes the issue. The comittee and the board are happy again 2.3. pTLP PMC doesn't fix the issue == GOTO #3 (we are expecting the level of maturity and dedication from the committee members so that GOTO #2 becomes impossible since the board explicitly flagged this issue in 2.1) END RESULT: no additional work for the board 3. pTLP is NOT doing fine and it gets flagged by the committee, which means: 3.1. since committee is treated as an extension of the board, its authority and the gravity of its opinion have exactly the same consequences if the board flagged it (we may need to come up with additional steps for the board to vet the committee's opinion, though) 3.2. the committee STILL is not responsible for fixing the problem, the PMC is. END RESULT: no additional work for the board Essentially, the overseeing committee acts as an extension of the board, but the ultimate responsibility lies with pTLP PMCs. In that sense the overseeing committee inherits the good and the bad sides of the board. More specifically: 1. it becomes a jackhammer, not a scalpel 2. it is NOT expected to fix the problem, but rather unearth it and delegate the solution to the PMC 3. if PMC doesn't act *really* grave consequences could follow 4. the level of maturity and the size of the committee needs to be as close to the board's level as possible. That is the part that is nicely addressed in Benson's wiki. Here's an elevator pitch: when it comes to running the foundation according to the 'Apache Way', the committee is a vice-board. 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. In that sense, Rich's idea couldn't have been timelier. Honestly, I really feel we've collectively stumbled on something really promising here. It's not necessarily a bad thing and may be acceptable to the board, but I don't understand why proponents of this approach feel it is a solution rather than a moving of the problem. Benson, another useful section on the wiki could be explicit listing of the benefits of the proposal. Here's
RE: Incubator report sign-off
Thanks Roman, this looks like a really good step forward. With these modifications this proposal is very similar to my original proposal to have a subset of the PMC act like the board and have all the authority of the board when dealing with podlings/pTLP or any other incubation vehicle we might want to try. I think I first made it about three years ago and have repeated it numerous times over the years, including recently in these thread. The first time I proposed this it got watered down into the shepherds role (which certainly helped but is not complete). I've talked to Sam about leveraging the tools we use for the board here in the IPMC. He says it would require a little work on both the tools and the processes but he is game for it. He's ready to discuss onlist if this is something that people want to explore, as am I. It also occurs to me that this same committee could perform the periodic reviews Rich is proposing, using the same tooling. Any other of the many proposals can also work within this construct. Nothing here should be seen as mutually exclusive. All I'm trying to do is ensure that some group of people take responsibility. A bit of a rant follows feel free to stop reading now, I leave it for those who want to see into my reasoning ... Let's think about the work a Director should do when reviewing a report. It’s not reading the report and then ticking a box. It's reading a report, comparing it to previous reports. Taking a quick look at the tone of emails on the dev list. Looking at commit activity. Checking the private list is not too active and more. We have some great tools (thanks Sam) for helping with this process, but it's still time consuming. We also have the concept of Shepherds. Those shepherds are expected to fully review a projects report and status. They will typically spend 10 minutes more than other directors and will be able to answer any questions that come up in the meeting from other directors. To really review a project properly takes a good 10 mins for non-shepherds and 20-30 minutes for shepherds (at least that is how long *I* spend on each report, I think most, if not all, directors would say the same). This is the case if there is no difficulties. If there are difficulties you can be talking about hours. Even with no problems this is around half a day *extra* work for each *volunteer* board member to review the podling/pTLP/whetever reports properly. I don't know about other Directors but I can't afford another half day of distractions from my day job - my employer is already being very generous with my time for the ASF. As an example of how long it takes to decide whether or not action is taken let me give you two concrete examples. Last night I spent just over four hours reviewing the archives of a TLP to see if a potential problem was actually a problem. I've spent maybe another 2 hours in email threads on the topic. For another project a different director has spent what I would estimate to be at least three hours reviewing and addressing an issue while I've spent maybe an hour tracking those threads to see if I need to help out. That's just in the last week, just the items I'm aware of and it doesn't address other things the directors do on a weekly basis. If, however, we run the IPMC like the board with formal review meetings with identified responsible people (Bensons committee if you prefer that over my earlier proposals) then things start to look more manageable because the responsibility remains delegated across a larger team of people who are accountable. It gives a group of individuals the authority to act if and when they need to, just as the board does for TLPs. It need not be surgical (that's what mentors are for), but it does need to act. It also gives that group the recognition that they deserve do doing a job well. This is very similar to Bensons proposal with your modifications below. It just removes the need for the board to take on additional responsibility which, in my opinion, it doesn't have the time for even if one or two directors do (those directors can volunteer that time to the IPMC either as part of the core committee, to count ticks in boxes, to properly review podling status or to conduct parallel pTLP experiments or whetever). 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: Monday, January 5, 2015 3:39 PM To: general@incubator.apache.org; Benson Margulies Subject: Re: Incubator report sign-off I am clearly hitting my rate-limit with emails to general@, still since Ross' reply was one of the few pieces of feedback from the board, I'll do this one and then wait for others to chime in (Benson?). On Mon, Jan 5, 2015 at 2:27 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: This proposal is not necessarily
RE: Incubator report sign-off
Careful... most mentors do a great job. The problem is when all mentors fade away (which as volunteers they are entitled to do) and the IPMC doesn't notice. Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Alan Cabrera [mailto:l...@toolazydogs.com] Sent: Monday, January 5, 2015 4:50 PM To: general@incubator.apache.org Subject: Re: Incubator report sign-off This statement confuses the lack of active mentors with the sheer size of the IPMC. The problem is not the size of the IPMC. The problem is that mentors are not doing their jobs Sent from my iPhone On Jan 5, 2015, at 3:41 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: Yep and let all from that 170+ person committee be tracked down for responsibility. Talk about s fun activity it's simply not scalable Sent from my iPhone On Jan 5, 2015, at 1:08 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: But the board is not responsible for any actions resulting from those reviews, the IPMC is. Ross -Original Message- From: Mattmann, Chris A (3980) [mailto:chris.a.mattm...@jpl.nasa.gov] Sent: Monday, January 5, 2015 9:31 AM To: general@incubator.apache.org Subject: Re: Incubator report sign-off It’s not a pawning off to the board - the board is already responsible for reviewing the IPMC report which includes *all of the same detail* that the IPMC also .. reviews. Cheers, Chris -Original Message- From: Alan D. Cabrera l...@toolazydogs.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Monday, January 5, 2015 at 8:59 AM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: Incubator report sign-off On Jan 5, 2015, at 8:22 AM, Roman Shaposhnik ro...@shaposhnik.org wrote: On Mon, Jan 5, 2015 at 5:05 AM, Alan D. Cabrera l...@toolazydogs.com wrote: On Dec 22, 2014, at 8:42 AM, Roman Shaposhnik r...@apache.org wrote: 1. get rid of IPMC altogether and move to the pTLP model This is effectively an IPMC reboot. I don’t really see anything substantially different. At this point, I'm convinced this is the only fruitful path forward, the rest is a shell game with responsibility. See the other thread. 3. patch the current process with starting to drop the mentors from the project who don't sign off. This will essentially serve as a heartbeat for mentors (now, in my opinion it'll quickly deteriorate into mindless tick-offs -- but at least it does not harm). How is it that a mentor became an IPMC member and do such an unethical thing such as a mindless tick-off? We're talking about human being here. The one who never ever cut corners in his life can cast the first stone. I think that you misunderstood my rhetorical question. It is my experience/understanding that if a mentor makes an effort to review reports/releases then this mentor is actually doing a good job at it. It is my experience/understanding that the overwhelming problem is that mentors simply go MIA and do nothing at all. I am in favor of #3 since it holds mentors accountable. #1 is simply a washing of our hands and pawning the problem off on the board simple because some of us are unwilling to do uncomfortable things. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org B C B [ 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 Т ÐÐ¥Fò Vç7V'67–RÂRÖ֖âvVæWÂ×Vç7V'67–T–æ7VF÷æ6†Ræ÷pФf÷FF —F–öæÂ6öÖÖæG2ÂRÖ֖âvVæWÂÖ†VÇ–æ7VF÷æ6†Ræ÷pÐ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Incubator report sign-off
But the board is not responsible for any actions resulting from those reviews, the IPMC is. Ross -Original Message- From: Mattmann, Chris A (3980) [mailto:chris.a.mattm...@jpl.nasa.gov] Sent: Monday, January 5, 2015 9:31 AM To: general@incubator.apache.org Subject: Re: Incubator report sign-off It’s not a pawning off to the board - the board is already responsible for reviewing the IPMC report which includes *all of the same detail* that the IPMC also .. reviews. Cheers, Chris -Original Message- From: Alan D. Cabrera l...@toolazydogs.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Monday, January 5, 2015 at 8:59 AM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: Incubator report sign-off On Jan 5, 2015, at 8:22 AM, Roman Shaposhnik ro...@shaposhnik.org wrote: On Mon, Jan 5, 2015 at 5:05 AM, Alan D. Cabrera l...@toolazydogs.com wrote: On Dec 22, 2014, at 8:42 AM, Roman Shaposhnik r...@apache.org wrote: 1. get rid of IPMC altogether and move to the pTLP model This is effectively an IPMC reboot. I don’t really see anything substantially different. At this point, I'm convinced this is the only fruitful path forward, the rest is a shell game with responsibility. See the other thread. 3. patch the current process with starting to drop the mentors from the project who don't sign off. This will essentially serve as a heartbeat for mentors (now, in my opinion it'll quickly deteriorate into mindless tick-offs -- but at least it does not harm). How is it that a mentor became an IPMC member and do such an unethical thing such as a mindless tick-off? We're talking about human being here. The one who never ever cut corners in his life can cast the first stone. I think that you misunderstood my rhetorical question. It is my experience/understanding that if a mentor makes an effort to review reports/releases then this mentor is actually doing a good job at it. It is my experience/understanding that the overwhelming problem is that mentors simply go MIA and do nothing at all. I am in favor of #3 since it holds mentors accountable. #1 is simply a washing of our hands and pawning the problem off on the board simple because some of us are unwilling to do uncomfortable things. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org 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
RE: Reflections from the outgoing Chair
The problem I am concerned with is the lack of mentoring support in a small number of projects and the fact the IPMC doesn't handle those situations well. Other than that I agree with Marvin - the IPMC usually does a fantastic job Sent from my Windows Phone From: Marvin Humphreymailto:mar...@rectangular.com Sent: 1/1/2015 7:51 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Reflections from the outgoing Chair On Thu, Jan 1, 2015 at 5:32 PM, Benson Margulies bimargul...@gmail.com wrote: three cheers for Roman for all his hard work! +1! +1! +1! For all other projects in the Foundation, we say, 'The chair is just a clerk who facilitates communications with the board.' Here at the IPMC, we expect the chair to be moderator of a very fractious set of arguments about how to incubate (or whether to even have an incubator). A leader, even. For this reason, no one who runs for IPMC Chair will receive my support unless they pledge to serve for a limited duration. It is my impression that no one is very happy with the current state of the incubation process. I dissent. The Incubator is functioning about as well as it could under difficult circumstances, and I am extremely proud of our ongoing work. Including all that you do, Benson! The problems faced by the Incubator are the inevitable consequence of flaws in the Apache Software Foundation and The Apache Way. * We are expected to teach The Apache Way, but The Apache Way has no authoritative definition. * We are expected to enforce Apache policy, but the the documentation of Apache policy is a sprawling, incoherent mess. Yes, incubator.apache.org is awful, but so is www.apache.org/devhttp://www.apache.org/dev and community.apache.org. Why can't Apache produce decent policy? For the same reason that projects under Apache governance produce notoriously bloated APIs. * Consensus requirements make it all but impossible to remove complexity. * Openness requirements bias the system towards adding complexity. People should leave the Incubator alone and go work on more pressing problems. Come back once the ASF has policies normal people can understand. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Process over Ego [Was: Re: Incubator report sign-off
Inviting those people to become members is a good idea (and in fact was agreed a long time ago when we brought the first non-members into the IPMC). I think we have a number of members now who started out as IPMC members. It is clear (at least to me) that anyone who proves themselves to be a good mentor should be a Member. However, you can't promote people to ComDev. ComDev is a project like any other. If folks want to show up there and do work they will be welcomed like any other volunteer. However, we can't assume that people signing up to the IPMC are also interested in the work ComDev do. At this time ComDev is *not* responsible for incubation processes, the IPMC is. Of course what ComDev does is dependent on who shows up there to help. The idea of moving incubation to ComDev has been discussed many times (or more accurately the maintenance of the incubation process and docs). However, to date nobody has joined ComDev to make it happen and the existing ComDev team signed up for a different purpose. As for the board ignoring the problem it should be understood the board have delegated the incubation process to the IPMC. It is the IPMC that need to solve the problem - not the board. However, lets not pretend the board are ignoring things. Take a look at who it is that brings this up every x months. It's always the board. Now, if the current chair and the IPMC really feels that disbanding the IPMC is the right solution then submit a resolution to do so. That will make it a board problem, until then it is an IPMC problem. Ross -Original Message- From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman Shaposhnik Sent: Tuesday, December 30, 2014 8:25 PM To: general@incubator.apache.org Subject: Re: Process over Ego [Was: Re: Incubator report sign-off On Tue, Dec 30, 2014 at 9:48 AM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: So, promote those 20 people to ComDev PMC, promote them to ASF members, promote them however, my guess is that they *care* about the foundation; we want these people helping new projects, and they will continue to help those new projects - along with the board - along with everyone else. Thank you! Thank you for saying out loud what has become painfully obvious for me during the course of my tenure as an IPMC Chair. Personally, I see this as the only *honest* way forward. But I guess, IPMC has become too convenient a way for everybody to ignore the real problem. Including, I am sorry to say this, the board itself. I think it is time we address it instead of blindly going through the motions. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Running an experiment with pTLP
I don't want to fan flames or point fingers, but at the same time I need to say this. Please read it as being intended to be constructive... This whole pTLP thing is not new. We conducted an experiment like the one proposed below some time ago. The outcome of that experiment was supposed to be a proposal to the board from the IPMC about how to create and manage pTLP's at scale. At the start of that experiment I (as Champion) spent a long time collating the various views on the proposal. I provided this as summary email at the start of the podlings life. I believed this was a really good start for whoever was going to turn it into a full proposal. It might be useful here also. NOTE - I'm not naming the podling or mentors to minimize the chance of people feeling that I'm finger pointing in the following paragraphs - there are plenty of folks around who will have that email in their archives. Unfortunately the experiment did not go well. No proposal was received and, more importantly, as champion (but not a mentor) for the project in question I was asked to step in on three separate occasion. This was despite, or perhaps because of, there being some very old hands in the podling committer list. My point today is just the same as it was when this was discussed the first time around. This proposal simply moves the problem (projects lacking in appropriate mentorship) to someone else's doorstep. It does not solve the problem itself. To be clear, I have no intention of voting against the proposed experiment. I do want to see the experiment take place (just as I did the first time around) but we need to ensure we are not simply moving the oversight role - that is not the problem that needs solving. Ross -Original Message- From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] Sent: Tuesday, December 30, 2014 2:39 AM To: Incubator General Subject: Re: Running an experiment with pTLP On Tue, Dec 30, 2014 at 12:14 AM, Roman Shaposhnik r...@apache.org wrote: ...Given that I'll be mentoring Zeppelin, I'd love to use that as a guinea pig. Provided, that I'd have some level of collaboration from the board I don't have a clear idea of what the suggested experiment means, it looks like that info is scattered around several threads that I have lost track of. A brief definition on a wiki page would help make sure everybody has the same view of what you are suggesting. -Bertrand - 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
John, Actually John I disagree with one of your examples (Ripple). This is actually a case where things have gone as they would expect. The mail you link to is from me. I had previously made the IPMC aware of the issue prior to that email on the mailing list. I was asked if I was undertaking to fix it (I replied yes and requested the podling added me as a mentor in order to do so). The podling report indicated that getting a release out was a focus No release made as yet, this will be the first item to recieve attention. The report does not need more detail than that since the IPMC had already been made aware that there was a problem, that it had been spotted and that the community and mentors indicated that they were to address it. Finally, if you review the shepherds notes from that report they acknowledge the concern and the fact that there was activity to address it. Ripple still has not addressed the issue raised those emails. Therefore it will not graduate until it does. The email you link to makes this perfectly clear. This is, in my opinion, exactly what should be happening. We provide oversight to ensure project acts as an Apache project. If it does so we graduate it, if it doesn't we retire it. I do agree with the overall intention of your mail, but it seems I disagree on what adequate oversight is. Ross -Original Message- From: John D. Ament [mailto:johndam...@apache.org] Sent: Tuesday, December 30, 2014 7:47 PM To: general@incubator.apache.org Subject: Re: Incubator report sign-off On Tue Dec 30 2014 at 1:26:31 PM Ted Dunning ted.dunn...@gmail.com wrote: On Tue, Dec 30, 2014 at 7:26 AM, John D. Ament john.d.am...@gmail.com wrote: Absolutely not just noise. Take the extra 2 seconds to add your sign off. I disagree. Checking a check box is much different than adding meaningful comments, either on mailing lists or on the report itself. For example, which gives you better info that I feel confident in Tamaya's board report. My check here: https://wiki.apache.org/incubator/December2014 or my comments in this thread: http://mail-archives.apache.org/mod_mbox/incubator-tamaya- dev/201411.mbox/%3CCAOqetn8wkYuDNkTwkpKKOGzu%3Ds_cf4VMT5A9_e8mdpM6mOh- 6Q% 40mail.gmail.com%3E All the check does (from my point of view) is give someone a brief summary that things are looking good. The check mark doesn't imply any due diligence on the mentor's part. It's very misleading to see it that way. Take a look for example at the log4cxx2 podling's report. It has mentor sign off, but the contents are barely present. The only reason it has mentor sign off is because the mentor wrote the report, after I (as the shepherd) reminded the podling. John, Are you seriously suggesting that the board should be delving into all the incubator mailing lists to determine whether you are paying attention to your mentoree groups? No, not in the slightest. But someone needs to look at it. Our current notion of a board report is completely on the honour system. It doesn't safeguard from the chance (which from what I can tell is more often the case) of a mentor writing and signing a report saying it's good to go. You can see some examples of this effect here: http://mail-archives.apache.org/mod_mbox/logging-log4cxx-dev/201412.mbox/%3C1418063938.3890690.200338789.1D0EE7B3%40webmail.messagingengine.com%3E There are also cases where there are clear issues w/ the podling but aren't getting communicated properly on the report (or maybe just oversight?) http://mail-archives.apache.org/mod_mbox/incubator-ripple-dev/201412.mbox/%3CBY2PR03MB490FFD83B71E97C269A12DF99660%40BY2PR03MB490.namprd03.prod.outlook.com%3E My point is that just because there's a checkbox checked doesn't mean there's issues. Maybe what would help is to have, during shepherd perhaps, some coaxing in to putting more into the issues for the IPMC/board section. Maybe it's more of a don't hesitate to put something in that area thing that needs to happen. John The check-box is the concise way that you indicate that the activity on the mailing lists is happening. There is a known defect with checkboxes in that they can be ticked without mentoring activity behind them, but that doesn't mean that we should introduce a new failure mechanism where there is good activity but no tick box. Yes, the tick box is supposed to be an echo. It is a redundant summarization. And it is very helpful because all the tick boxes are in one place for easier review.
RE: Incubator report sign-off
:-) Yes, it is shocking that the Ripple project had a number of signed off reports while inappropriate releases were being made. This problem only came to light because the community was considering retirement and some of my day job colleagues wanted me to look at it. In other words, I have a vested interest in seeing if things can be fixed, so I stepped up to see if they can. This is at the root of my proposal to *expect* mentors to have a vested interest in the success of a project. Ross -Original Message- From: John D. Ament [mailto:johndam...@apache.org] Sent: Tuesday, December 30, 2014 8:05 PM To: general@incubator.apache.org Subject: Re: Incubator report sign-off Ross, I think we're actually on the same page. My point with ripple was not so much that it wasn't bringing it to anyone's attention (in fact the opposite, it's plastered all over the report) but more that a simple checkbox doesn't mean everything's great. John On Tue Dec 30 2014 at 10:59:33 PM Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: John, Actually John I disagree with one of your examples (Ripple). This is actually a case where things have gone as they would expect. The mail you link to is from me. I had previously made the IPMC aware of the issue prior to that email on the mailing list. I was asked if I was undertaking to fix it (I replied yes and requested the podling added me as a mentor in order to do so). The podling report indicated that getting a release out was a focus No release made as yet, this will be the first item to recieve attention. The report does not need more detail than that since the IPMC had already been made aware that there was a problem, that it had been spotted and that the community and mentors indicated that they were to address it. Finally, if you review the shepherds notes from that report they acknowledge the concern and the fact that there was activity to address it. Ripple still has not addressed the issue raised those emails. Therefore it will not graduate until it does. The email you link to makes this perfectly clear. This is, in my opinion, exactly what should be happening. We provide oversight to ensure project acts as an Apache project. If it does so we graduate it, if it doesn't we retire it. I do agree with the overall intention of your mail, but it seems I disagree on what adequate oversight is. Ross -Original Message- From: John D. Ament [mailto:johndam...@apache.org] Sent: Tuesday, December 30, 2014 7:47 PM To: general@incubator.apache.org Subject: Re: Incubator report sign-off On Tue Dec 30 2014 at 1:26:31 PM Ted Dunning ted.dunn...@gmail.com wrote: On Tue, Dec 30, 2014 at 7:26 AM, John D. Ament john.d.am...@gmail.com wrote: Absolutely not just noise. Take the extra 2 seconds to add your sign off. I disagree. Checking a check box is much different than adding meaningful comments, either on mailing lists or on the report itself. For example, which gives you better info that I feel confident in Tamaya's board report. My check here: https://wiki.apache.org/incubator/December2014 or my comments in this thread: http://mail-archives.apache.org/mod_mbox/incubator-tamaya- dev/201411.mbox/%3CCAOqetn8wkYuDNkTwkpKKOGzu%3Ds_cf4VMT5A9_e8mdpM6mO h- 6Q% 40mail.gmail.com%3E All the check does (from my point of view) is give someone a brief summary that things are looking good. The check mark doesn't imply any due diligence on the mentor's part. It's very misleading to see it that way. Take a look for example at the log4cxx2 podling's report. It has mentor sign off, but the contents are barely present. The only reason it has mentor sign off is because the mentor wrote the report, after I (as the shepherd) reminded the podling. John, Are you seriously suggesting that the board should be delving into all the incubator mailing lists to determine whether you are paying attention to your mentoree groups? No, not in the slightest. But someone needs to look at it. Our current notion of a board report is completely on the honour system. It doesn't safeguard from the chance (which from what I can tell is more often the case) of a mentor writing and signing a report saying it's good to go. You can see some examples of this effect here: http://mail-archives.apache.org/mod_mbox/logging-log4cxx- dev/201412.mbox/%3C1418063938.3890690.200338789.1D0EE7B3% 40webmail.messagingengine.com%3E There are also cases where there are clear issues w/ the podling but aren't getting communicated properly on the report (or maybe just oversight?) http://mail-archives.apache.org/mod_mbox/incubator-ripple- dev/201412.mbox/%3CBY2PR03MB490FFD83B71E97C269A12DF99660%40BY2PR03MB490. namprd03.prod.outlook.com%3E My point is that just because there's a checkbox checked doesn't
RE: Incubator report sign-off
Part of the apache way is to recognize all contributions. That's why I wrote active participant of the project ... and generally engaging with the community The key part is requiring active participation as a community member. That is vested interest in the project itself rather than simply saying sure I'd like to see more projects at the ASF Sent from my Windows Phone From: Rich Bowenmailto:rbo...@rcbowen.com Sent: 12/29/2014 6:13 AM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Incubator report sign-off On 12/19/2014 02:00 PM, Ross Gardler (MS OPEN TECH) wrote: Strawman: What if a mentor is *required* to be an active participant of the project. That is contributing code, voting on releases and generally engaging with the community, they would be a better mentor since they have a vested interest in the project itself. Sure, we might reduce the number of projects coming into the foundation but (IMHO) that is not a problem. Our goal as a foundation is not to be large, it is to be high quality. The role of the Mentor is to coach the project into the Apache philosophy, not to guide the technical progress of the project. Requiring that they contribute code eliminates almost anyone that could participate on *most* of the projects that have come to the ASF in recent years, because almost all of them have been composed primarily of outsiders. Is that seen as a problem? --Rich -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Incubator report sign-off
In Apache there is no such thing as a Project Leader The PMC Chair has no more authority over the project than anyone else. The PMC Chair absolutely does *not* have the power to dissolve the PMC. Only the Board of Directors have that authority and they will only do that at the request of the PMC as a whole (or when there is no active PMC to make such a request). Ross -Original Message- From: Andrew Purtell [mailto:andrew.purt...@gmail.com] Sent: Monday, December 29, 2014 10:45 AM To: general@incubator.apache.org Subject: Re: Incubator report sign-off There are honorary and practical reasons why a project may view the PMC Chair and the project leader as one in the same. Honorary: The community elevated one member as lead and assigned the Chair role out of respect. Practical: The PMC Chair has the power to dissolve the PMC, and is an officer of the Foundation. Nobody else on the project has such power nor indemnification. Secretary as a term does not adequately encompass that. On Dec 29, 2014, at 6:46 AM, Rich Bowen rbo...@rcbowen.com wrote: On 12/23/2014 03:34 PM, sebb wrote: Flex had three great mentors, but to expect them to be the PMC Chair on graduation would have been problematic. They were great mentors because they had lots of experience from their work on other Apache projects, and thus didn’t have time to stay active on a new TLP, plus they really weren’t users or developers of the technology, just our coaches on the Apache Way, and thus wouldn’t be good Chair candidates as they weren’t as invested in the technology. But they did stick around on at least the private@ lists and continue to do so even 2 years after graduation where we consult them on occasion. To require that a mentor be an active contributor limits the kinds of technologies that can come to Apache to only those who can interest someone with a lot of spare cycles. IMO, the mentors job is to teach, not to lead. The job of the PMC chair is almost entirely administrative. They are the link between the board and the PMC and their main role is to ensure the board gets timely reports and to feed back comments from the board. If a PMC is relying on the chair to drive it forward technically, then I think something has gone wrong with the PMC. Indeed. Big +1 on this. There are some projects that I've been watching lately where the PMC chair is viewed as the project lead, and that has a number of problems that go along with it. The PMC chair is a secretary, whose job is to file the right paperwork. A *hugely* important role, but not a technical lead role. -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - 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
+1 well said. Sent from my Windows Phone From: Benson Marguliesmailto:bimargul...@gmail.com Sent: 12/29/2014 6:25 PM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Incubator report sign-off I'd like to look at this through a lens of failure analysis. How do podlings fail? I see two main patterns. 1. Failure to build a community. These are the podlings that we find adrift in space with the lights on but no one home on the mailing list. 2. Failure to build an _Apache_ community. These are the podlings that JimJag was referring to in another thread; they are here, perhaps, for the brand, perhaps launched/dumped here by a commercial enterprise. They have people, they make releases, but there's an empty resonant cavity where the Apache Way is supposed to be. We observe missing mentors in both cases, but I claim that it's only a serious problem in the second case. In the first case, the problem isn't lack of supervision. Here is where the 'Mentors in the Project' (whether directly reporting to the board or not) leaps up and looks like a great idea to me. The whole goal of incubation is to run an Apache project on training wheels. How does an Apache project run? WIth a chair and PMC members supervising it and _reporting to the board_. The proposal, as I see it, is to tell the champion and other mentors that they, and not the entire IPMC in some nebulous fashion, are the PMC in the PPMC. By the time the podling graduates, their need to have expanded themselves to a larger group. The board may choose to keep the IPMC around to organize and support this process. The board may choose to continue to ask the IPMC to add an extra layer of supervision. But the heart of the proposal is to insist that every podling be nucleated around at least three people who have the experience to operate as a PMC and have volunteered for the responsibility. On Mon, Dec 29, 2014 at 7:01 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: On Mon, Dec 29, 2014 at 6:40 AM, Rich Bowen rbo...@rcbowen.com wrote: Roman, please forgive me absence from this conversation. I started the thread, and then went on Christmas vacation. I am still on vacation for another week, but will attempt to keep up with the conversation here, and not abandon the thread I started. Please also forgive the dozen responses that I'm dropping all at once. This totally makes two of us. Every time Christmas season begins this is very much the predicament I find myself in. Thanks, Roman. P.S. Not even sure whether it would be better to simply go away 100% so at least folks get a nice auto-responder email while I can't be present anyway. - 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: [DISCUSS] How do podlings add new mentors?
I always thought this was the case, so +1. That being said, there does not (should not?) need to be a special process - this is open source anyone can get involved by just by showing up and helping. If the individual wants to be involved in the project then the title mentor isn't (shouldn't be?) important. Mentors have less authority in a (well-functioning) project than the committers do anyway. Since a mentor must be an IPMC member their utility for binding votes is present regardless of the mentor title. -Original Message- From: Mattmann, Chris A (3980) [mailto:chris.a.mattm...@jpl.nasa.gov] Sent: Wednesday, December 24, 2014 9:54 AM To: general@incubator.apache.org Subject: Re: [DISCUSS] How do podlings add new mentors? +1 ++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ -Original Message- From: Ted Dunning ted.dunn...@gmail.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Wednesday, December 24, 2014 at 9:37 AM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: [DISCUSS] How do podlings add new mentors? On Wed, Dec 24, 2014 at 9:35 AM, jan i j...@apache.org wrote: On Wednesday, December 24, 2014, John D. Ament johndam...@apache.org wrote: ... I'd like to propose that a mentor should be able to join an existing podling after volunteering and the PPMC of that podling agrees to it (via lazy consensus). No required general@ or private@i.a.o votes required. +1 no need to make it more difficult. ... +1 as well. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Incubator report sign-off
Yay progress! +1 Thanks Roman (and everyone else on the thread) Sent from my Windows Phone From: Roman Shaposhnikmailto:r...@apache.org Sent: 12/22/2014 8:42 AM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Incubator report sign-off Hi! before answering Ross' proposal, I'd like to remark that I was holding off on replying to see whether viewpoints that we haven's seen before would emerge. It seems that they didn't. It seems that we're still limited by the following options wrt. resolving mentors AWOL issues: 1. get rid of IPMC altogether and move to the pTLP model 2. make this a poddling issue: if a poddling fails to hunt down ALL the mentors for a sign-off -- reject its report 3. patch the current process with starting to drop the mentors from the project who don't sign off. This will essentially serve as a heartbeat for mentors (now, in my opinion it'll quickly deteriorate into mindless tick-offs -- but at least it does not harm). FWIW, I personally think #2 is a useless middles ground and if we really feel like #2, we may as well man up and do #1. Frankly, I'd be appalled to remain part of IPMC that treats its podlings like #2 without providing even the slightest accountability for its own members. Thus, to me, the choice is really about #1 and #3. So perhaps, the path forward is to try #3 first and then, if things don't improve, go all the way to #1. Please let me know what do you think. And now to comment on Ross's proposal. The only one that addressed my original issue of lack of clear RR understanding (which I think everybody else, with an exception of folks bringing up #1 is avoiding): On Fri, Dec 19, 2014 at 11:00 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Strawman: What if a mentor is *required* to be an active participant of the project. That is contributing code, voting on releases and generally engaging with the community, they would be a better mentor since they have a vested interest in the project itself. Well, than I suggest we solicit an opinion on this list of how many mentors will remain if the requirement is to be put in place. I can tell you this much: personally I will have to resign from every single poddling I am currently mentoring. There is absolutely no way I can promise the level of commitment that goes beyond helping them with 'the Apache Way' and releases. IOW, if I were to be required to understand their technology -- I don't think I can stay. Sure, we might reduce the number of projects coming into the foundation but (IMHO) that is not a problem. Our goal as a foundation is not to be large, it is to be high quality. But it is to be high quality on the level of understanding of the 'Apache Way' which has very little to do with the quality of code, documentation or any other piece of technology. We could scrap the role of shepherd and change the role of mentors. A team of 9 mentors would meet monthly to review *all* podlings reports (as submitted by the champion). Their responsibility is not to engage with the projects but to review the reports crafted by the champion. Any follow up actions would be taken by a single mentor and podlings (especially the champion) are expected to address the issues raised. I actually like this proposal, but only if we can cut out the middleman alltogether. What you're describing is essentially pTLPs. Which is a fine idea. The champion is still answerable to the podling community. Where conflict arises within the community they can call upon the IPMC mentoring team to ask for independent guidance. Let me ask you this: do you think it would be worth our while to try this without any other changes? IOW, make #2 a champion's problem, instead of poddling's problem? No other changes needed. I look forward to the PMC tearing this strawman proposal apart and (most importantly) suggesting alternatives That was my expectation as well. Sadly, I don't think we've got too many alternatives :-( 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
Strawman: What if a mentor is *required* to be an active participant of the project. That is contributing code, voting on releases and generally engaging with the community, they would be a better mentor since they have a vested interest in the project itself. Sure, we might reduce the number of projects coming into the foundation but (IMHO) that is not a problem. Our goal as a foundation is not to be large, it is to be high quality. Maybe we should simply scrap the idea of mentors and change the role of the champion to one of an initial committer who will help build an Apache project as it incubates and into being a TLP. We could scrap the role of shepherd and change the role of mentors. A team of 9 mentors would meet monthly to review *all* podlings reports (as submitted by the champion). Their responsibility is not to engage with the projects but to review the reports crafted by the champion. Any follow up actions would be taken by a single mentor and podlings (especially the champion) are expected to address the issues raised. If a champion's priorities change during the course of incubation then the project must find another champion (potentially from within their own ranks) who is sufficiently qualified and committed to take on the responsibility. The important thing is that the Champion is personally invested in seeing the podling succeed and acts as a true mentor (as opposed to someone with a title and an entry on a web page). The champion is still answerable to the podling community. Where conflict arises within the community they can call upon the IPMC mentoring team to ask for independent guidance. This model is almost identical to the way the board and TLPs work (where Champions are roughly equivalent to PMC Chairs and mentors (nee shepherds) are roughly equivalent to Directors and he monthly meeting is roughly equivalent to the monthly board meeting to review TLP reports). I've designed it this way (and proposed the same solution before) because it is proven to work for TLPs and we have tooling to assist with the process. I look forward to the PMC tearing this strawman proposal apart and (most importantly) suggesting alternatives and/or tweaks of value. We've been skirting this issue for far too long. Things have improved (thanks to all who have worked hard on this), but we have not yet solved the problem. 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: Friday, December 19, 2014 10:11 AM To: general@incubator.apache.org Subject: Re: Incubator report sign-off Hi Rich! Thanks for raising this point and giving us a bit more of a forcing function to tackle an old problem: accountability for mentors. On Fri, Dec 19, 2014 at 9:10 AM, Rich Bowen rbo...@rcbowen.com wrote: I certainly don't expect that every mentor has their full attention on a podling every month, but I do expect that a podling that cares about its incubation will seek out that mentor sign-off, and that the mentors who have committed to help a podling into the family will have a few moments every few months to look in and approve a report. I've been thinking about this for quite some time (and trying to seek a solution by various means) and it seems to be that we have to start from a very basic expectation setting. First of all, *my* expectation is that multiple mentors on the project are more of redundancy or HA consideration. IOW, my expectation that a project needs to have at least one active mentor at all times, but it doesn't have to be the same person. Thus, I expect at least a signle sign-off on the report and I don't mind if it ends up being a single one too much. Second biggest expectation that I have is that mentors are extension of the IPMC, not part of the poddling. They are akin to professors or faculty members -- they are not part of the student body. As such we, as IPMC are accountable to make sure that mentors perform their duties. My expectation is that it is as unfair to ask poddling to actively pursue mentors who are missing in action as it would be unfair to ask students to hire detectives to hunt down professors who don't show up for class. What is fair, is to provide poddlings with a semi-format feedback channel for IPMC to monitor things like mentors MIA. I would like to pause here and ask everybody to chime in with what they thing are the right expectations on the above two points. But I wonder if we might, as the Board does, reject reports that have no sign-off, and force projects to report again the following month, in an attempt to require them to engage with their mentor(s) a little more? As was pointed by John, we're already rejecting reports with no mentor sign-off. Before we potentially take it one step further I'd like to get clarity on the expectations first (and then I can
RE: Incubator report sign-off
Assuming that the project VP is someone personally invested in the project I have no real problem with the core of this proposal. If they are not personally invested, if they are instead a semi-random person from the IPMC then I do not see how this will address the real problem (which is *not* having people tick a box on a report). I do question the need to dissolve the IPMC, but we've been over that before and at this point is probably an unnecessary distraction from the important topic of ensuring mentors have a vested interest in the project. Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Mattmann, Chris A (3980) [mailto:chris.a.mattm...@jpl.nasa.gov] Sent: Friday, December 19, 2014 11:21 AM To: general@incubator.apache.org Subject: Re: Incubator report sign-off And how could the below proposal return without me passing along my comment regarding it - if we’re going to emulate the board and TLPs, etc., why emulate it when we could cut through the middle man and simply rely on the board to do so? I guess to protect the board from an influx of “incubating” projects (+30-40 at this point in time?) I myself as a board member would welcome this. What it would do however if we simply did away with the notion of the IPMC/Incubator/etc., is to return to the notion of pTLPs which were proposed earlier which I would most wholeheartedly support. TL;DR 1. Incubation yes, Incubator no a. (all Incubator documentation, active folks, etc., become part of the pool of [incoming project VP]) b. IPMC is dissolved c. We create a new “Incubation PMC” that includes most active members of Incubator currently (those who are good at reviewing releases; watching projects, etc.) 2. All incoming projects are proposed directly as pTLPs (provisional TLPs) - provisional part is defined as: a. 3 members of new Incubation PMC from #1c assigned as PMC and potentially VP of incoming project b. PMC += all incoming folks from proposal c. board VOTEs to approve incoming projects d. project retirement happens same as it currently does, with Attic support To me this would solve the problem of AWOL or mentors who don’t sign off. Mentoring happens via new Incubation PMC who are assigned to the PMCs of incoming pTLPs. Project VP is either one of those Incubation PMC members, or via Ross’s suggestion below, the most active person or “Champion” of the incoming project. The health of these projects are monitored by the Incubation PMC and reported on monthly directly to the board instead of hidden inside the Incubator report each month, without sign off. All of the other problems would seem to go away too IMO. My 2c. Cheers, Chris -Original Message- From: Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Friday, December 19, 2014 at 11:00 AM To: general@incubator.apache.org general@incubator.apache.org Subject: RE: Incubator report sign-off Strawman: What if a mentor is *required* to be an active participant of the project. That is contributing code, voting on releases and generally engaging with the community, they would be a better mentor since they have a vested interest in the project itself. Sure, we might reduce the number of projects coming into the foundation but (IMHO) that is not a problem. Our goal as a foundation is not to be large, it is to be high quality. Maybe we should simply scrap the idea of mentors and change the role of the champion to one of an initial committer who will help build an Apache project as it incubates and into being a TLP. We could scrap the role of shepherd and change the role of mentors. A team of 9 mentors would meet monthly to review *all* podlings reports (as submitted by the champion). Their responsibility is not to engage with the projects but to review the reports crafted by the champion. Any follow up actions would be taken by a single mentor and podlings (especially the champion) are expected to address the issues raised. If a champion's priorities change during the course of incubation then the project must find another champion (potentially from within their own ranks) who is sufficiently qualified and committed to take on the responsibility. The important thing is that the Champion is personally invested in seeing the podling succeed and acts as a true mentor (as opposed to someone with a title and an entry on a web page). The champion is still answerable to the podling community. Where conflict arises within the community they can call upon the IPMC mentoring team to ask for independent guidance. This model is almost identical to the way the board and TLPs work (where Champions are roughly equivalent to PMC Chairs and mentors (nee shepherds) are roughly equivalent to Directors and he monthly meeting is roughly equivalent to the monthly board meeting to review TLP reports
