Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
On Fri, Jan 23, 2015 at 4:30 AM, Ted Dunning ted.dunn...@gmail.com wrote: On Fri, Jan 23, 2015 at 2:07 AM, Marvin Humphrey mar...@rectangular.com wrote: On Thu, Jan 22, 2015 at 4:14 AM, Ted Dunning ted.dunn...@gmail.com wrote: I really don't have a problem with a report like that going out as long as somebody can answer it. I answered it. Dave paid attention. The group gained more knowledge about which aspects of a release are important to Apache. It was a very good thing, all in all. But did that communication have to be *in the report*? I guarantee that other inaccurate shepherd reviews have slipped into the permanent record -- and that useful feedback has been self-censored by shepherds because that's the channel they are instructed to use. Why not just reply to the draft report that gets sent to general@incubator each month instead? My first reaction is that we need to make shepherding have higher rewards. Higher rewards, eh? I imagine reviewers would value having their feedback spawn give-and-take -- which would happen in email, but not so much via the report wiki. But really, the elephant in the room is cost. Why must proactive community assessment be a prerequisite to cross-cutting feedback? If the Incubator didn't insist on that, there would be more and richer critiques. There is *plenty* of information in podling reports to initiate cross-community conversations. A reactive workflow suffices. Maybe the time will come to revisit this issue if shepherd participation flatlines, though that's not a very satisfying outcome... Seems important enough to think about now. Time is on the side of those who think shepherd institution should die. It would be better if it died quickly, vacating the report review mindspace and making way for Mentor commentary supplemented by reactive IPMC report feedback. Mentors on the ground *are* the Incubator's analogue to Board shepherds -- the extra layer is unnecessary and costs too much. It is harmful that shepherd reviews are the way it's done. 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.)
On Fri, Jan 23, 2015 at 12:57 PM, Marvin Humphrey mar...@rectangular.com wrote: ... Time is on the side of those who think shepherd institution should die. It would be better if it died quickly, vacating the report review mindspace and making way for Mentor commentary supplemented by reactive IPMC report feedback. Mentors on the ground *are* the Incubator's analogue to Board shepherds -- the extra layer is unnecessary and costs too much. It is harmful that shepherd reviews are the way it's done. I believe the Incubator shepherds exist to help the IPMC with its duties. The shepherds delegate/divide the work needed of the IPMC to review the podling reports, before passing its report up to the Board. The IPMC is an active entity with responsibilities. It has a job to do, and the shepherds provide a way to do that. Rather than waving a hand and saying the IPMC will review (and nothing happening cuz everybody thinks everybody else will do it) ... or requiring the VP to do it every month.. the shepherds provide a way for volunteers to assist with the process. There is nothing stopping the IPMC from designating certain Mentors as shepherds for their podlings. Look at the Board: since I am the VP of Subversion, a shepherd is never assigned to that report. I'm the implied shepherd. Anything that the Board needs to convey to the PMC, I'm responsible for that legwork (just like we delegate working with PMCs to shepherds). So if a Mentor is active enough, then put your name on the list to be the shepherd for your podling (and be an IPMC member, of course). That activity wasn't happening in the past, so the shepherds were filling in. Especially when a Mentor is temporarily away. Cheers, -g
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Hi Greg, On Fri, Jan 23, 2015 at 1:33 PM, Greg Stein gst...@gmail.com wrote: There is nothing stopping the IPMC from designating certain Mentors as shepherds for their podlings. Having volunteers step forward as dedicated shepherds for individual podlings would be helpful. On its own, though, it is not sufficient, because Incubator shepherds are not as reliable as Board members. What happens when the dedicated shepherd goes missing? Podlings will start falling through the cracks again. An additional mechanism needs to be in place to ensure that no report goes unreviewed. For instance: 1. The Incubator doesn't file its report until each and every podling report has been reviewed by either a shepherd or a freelance IPMC member filling in. 2. Podling reports which have not been reviewed by a shepherd are omitted from the aggregate report and the podling is required to report again next month. Starting this month, the Incubator has instituted something similar to the second option: podling reports where not a single Mentor has signed off get rejected and the podling is required to report again next month[1]. There was criticism that this mechanism punishes a podling for the sins of its Mentors, but the intended result was achieved: every podling report got signed off. (Besides, in many cases the podling is at fault for filing at the last minute and leaving too small a window for Mentor signoff.) With signoff required, Mentors assume the essential functionality of shepherds, and the value added by the titular shepherds is limited to cross-cutting feedback. I maintain that there are better ways to provide such feedback. That activity wasn't happening in the past, so the shepherds were filling in. Shepherd participation has fallen too low to keep podlings from getting lost -- it's now below 50%. What has kept distressed podlings like NPanday from falling off the IPMC's radar screen, for the last year and a half, has been the Report Manager putting podlings who don't file reports into monthly reporting. It's not perfect, but it's *way* less work and more reliable than shepherds. Maybe the Incubator should strike that task from the Report Manager's runbook and start losing track of podlings again? Because I feel like we designed a better system and nobody noticed. Marvin Humphrey [1] This is related but not linked to the list of not-signing-off Mentors which the Board has chosen to remove from this month's report. I've remained silent about that up till now out of deference to those IPMC members who are working hard to address issues of Mentor accountability, but I support the Board's decision. - 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.)
On Fri, Jan 23, 2015 at 9:49 PM, Marvin Humphrey mar...@rectangular.com wrote: Hi Greg, On Fri, Jan 23, 2015 at 1:33 PM, Greg Stein gst...@gmail.com wrote: There is nothing stopping the IPMC from designating certain Mentors as shepherds for their podlings. Having volunteers step forward as dedicated shepherds for individual podlings would be helpful. On its own, though, it is not sufficient, because Incubator shepherds are not as reliable as Board members. What happens when the dedicated shepherd goes missing? Podlings will start falling through the cracks again. Agreed. I was thinking on a month-to-month basis. I'll shepherd ACME this month. (in addition to more general shepherds of gimme 3 podlings that haven't been allocated already) An additional mechanism needs to be in place to ensure that no report goes unreviewed. For instance: 1. The Incubator doesn't file its report until each and every podling report has been reviewed by either a shepherd or a freelance IPMC member filling in. Ah. I like the term freelance (better than my general above) ... note that the IPMC must file a report. It can't wait forever. I think what you're really looking for is fully-explained in your point below. (ie. not sure how the above is different than below) 2. Podling reports which have not been reviewed by a shepherd are omitted from the aggregate report and the podling is required to report again next month. yes, the above would work just fine. Get the podling report reviewed, or we strip it from the report to the Board. Of course, the corollary is that the Board will get a bit cranky if it keeps receiving empty Incubator reports :-P Starting this month, the Incubator has instituted something similar to the second option: podling reports where not a single Mentor has signed off get rejected and the podling is required to report again next month[1]. There was criticism that this mechanism punishes a podling for the sins of its Mentors, but the intended result was achieved: every podling report got signed off. (Besides, in many cases the podling is at fault for filing at the last minute and leaving too small a window for Mentor signoff.) *nod* ... It means get it in on time, and if your Mentors aren't helping, then find new ones. Unfortunately, we *have* had a case or three in the past where a podling has been unable to locate new Mentors. There isn't a good solution for that, under any plan :-( With signoff required, Mentors assume the essential functionality of shepherds, and the value added by the titular shepherds is limited to cross-cutting feedback. I maintain that there are better ways to provide such feedback. Fair enough. That activity wasn't happening in the past, so the shepherds were filling in. Shepherd participation has fallen too low to keep podlings from getting lost -- it's now below 50%. What has kept distressed podlings like NPanday from falling off the IPMC's radar screen, for the last year and a half, has been the Report Manager putting podlings who don't file reports into monthly reporting. It's not perfect, but it's *way* less work and more reliable than shepherds. It's an imperfect system, given volunteers, varying time, and changing interests. Maybe a call for new shepherds? Maybe a slight change in Mentors and their signoff? and as you note: maybe another way to create cross-cutting feedback outside of the Mentor/shepherd roles. (general@ is already a good mechanism for much of that) Maybe the Incubator should strike that task from the Report Manager's runbook and start losing track of podlings again? Because I feel like we designed a better system and nobody noticed. Marvin Humphrey [1] This is related but not linked to the list of not-signing-off Mentors which the Board has chosen to remove from this month's report. I've remained silent about that up till now out of deference to those IPMC members who are working hard to address issues of Mentor accountability, but I support the Board's decision. I believe the list of no-sign-off Mentors is very useful, and the Incubator should have that data. With the right context, it makes sense and is helpful. It can help identify where a Mentor is slipping and needs encouragement, replacement, or more Mentors for a podling. However, the Board minutes do not provide the context. He was on vacation doesn't appear, so it is easy to misconstrue what that list means. And it is a bit too fine-grained for the Board. Replacing that list with something like we had 30 active Mentors, and are reaching out to 4 that appear to have moved on would be something the Board would be interested in. That is about the *health* of the mentoring program, rather than calling out names. (in fact, we asked a PMC or two to remove individual names from reports over the past couple months; longer discussion on why) Cheers, -g
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
On Fri, Jan 23, 2015 at 2:07 AM, Marvin Humphrey mar...@rectangular.com wrote: 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. Hmm... you link to my own response there. This shepherd report was actually one of the things that I found really helpful in mentoring (and contributing to) on the Drill incubation. I really don't have a problem with a report like that going out as long as somebody can answer it. I answered it. Dave paid attention. The group gained more knowledge about which aspects of a release are important to Apache. It was a very good thing, all in all. 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. My first reaction is that we need to make shepherding have higher rewards. Maybe we make a rule that one isn't supposed to mention mentor status publicly, but can put shepherd work on your resume. :-) / 2 Maybe the time will come to revisit this issue if shepherd participation flatlines, though that's not a very satisfying outcome... Seems important enough to think about now.
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.)
Niclas, I merely speak about what I experienced. My experience is that shepherds provided valuable help to me while I was acting as a mentor. This was (as I understand it) part of the expectation for shepherds. The board has never provided me specific help like this in mentoring. I don't think that it was ever expected that they would. If you would like to characterize shepherds as cross-cutting mentors-at-large, I wouldn't disagree. I don't much care about names unless they confuse people. I really did appreciate the help when I got it. From your tone, however, it sounds like you would like for me to disagree with something you say. I can't figure out what it is that I should disagree with. On Thu, Jan 22, 2015 at 2:06 AM, Niclas Hedhman nic...@hedhman.org wrote: 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.)
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.)
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.)
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
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.)
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.)
On Wed, Jan 21, 2015 at 11:53 AM, Alan D. Cabrera l...@toolazydogs.com wrote: On Jan 21, 2015, at 3:39 AM, Benson Margulies bimargul...@gmail.com wrote: On Wed, Jan 21, 2015 at 4:03 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Jan 20, 2015 at 9:38 PM, Chris Douglas cdoug...@apache.org wrote: On Mon, Jan 19, 2015 at 11:57 PM, Bertrand Delacretaz bdelacre...@apache.org javascript:; wrote: How is that different from pruning the current IPMC membership by removing inactive members? Doing *that* would be straightforward. Take the set of mentors on currently incubating projects, add the other half dozen who review releases, and set everyone else to voluntary emeritus status. Done Agreed - but I don't see how that improves things anyway, I don't see any problem caused by those inactive members. The near-ad-hominem tone of this thread has extracted a reply in my own defense. It is a misunderstanding, verging on willful, to claim that the V2 proposal is primarily intended to remove either inactive or noisy persons from the group. it is a fabrication that there is any idea that some person other than the board might select an initial set of people to further some particular agenda. The idea here of the small group, extracted from something Ross wrote on the Wiki in 2013, is that an incubator committee doesn't need to be big and it doesn't need to grow via merit, if its only job is to accept the board's delegation of a limited set of supervisory tasks. If you make a smaller group, it might still contain vigorous disagreement, but on a scale where they can manageably reach consensus. It would think less of the board if they failed to select people likely to have some significant disagreements. I resent your and Chris’ characterization of this thread. All that’s been taking place is a frank and civil discussion of opinions as to what the implication of some proposals mean. Your, and Chris’, attempt to characterize them as taking on an ad-hominem tone suggest to me that we are poking at the Achilles heal of the Iv2 proposal and Chris’ impromptu proposal to fork the Incubator. Since it is the tone of Chris' messages that I am predominantly objecting to, I am nonplussed. Since the purpose of V2 was to highlight my perception of the Achilles heel of pTLP, or alternatively to try to build the rest of the structure it required, I am bemused to see you looking for a heel of a heel. Would it help if I deleted the silly thing? No one seems to like it, and it is failing as a tool to focus discussion on my perceptions of the missing parts of the pTLP idea. No one seems to express any affirmative interest. All it seems to do is provoke ventilation. It is certainly true that you and I have very different views of the essential character of the some of the issues, but I see no value to this discussion, the incubator, or the asf in trying any further to bridge the gap. I, personally, would be happy to see effort put into Marvin's documentation project first and foremost, and any discussion about radical or structural changes to incubation deferred until we see the impact of that project. I, personally, would be happy to see the Board establish an 'unincubated' project now and again when there is a nuclear group of people qualified to run it without IPMC supervision. I, personally, prefer that the legal structure of a thing like an incubator match the function, but I accept that I'm apparently unique. But I have a very hard time typing nothing when there are people repeatedly accusing me, personally, of conspiratorial intentions. You and other, feel that the effect of V2 would be to exclude. Fine. That's a great reason to oppose it. (And also the change to ApacheCon.) But I perceive trolling, or worse, when people choose to oppose it by claiming that I drafted it with the intention of taking control by stuffing a committee with my co-thinkers. That's the plain sense of what Chris wrote, and I don't like it. At the heart of both there is a culling of IPMC members. Sure, the new IPMC may have Oscar Madison” and “Felix Ungar” tossed into the same bag but that’s a distraction from the real problem that I, and maybe Bertrand, are trying to point out. At the proposals' core is that there are IPMC members who want to participate but would be left out and in the end the “problems” with the Incubator would not be resolved since, as Chris accurately puts it, we will have distilled dysfunction. But is it dysfunctional? Only when it tries to be like a school of business and come up with new and improved processes for bringing in new projects instead of focusing on the core problems which don’t go away, tooling and mentor accountability. Otherwise, I think we do a pretty good job. We make mistakes, sure, but mistakes will always be made and I think we’ve made good, focused, incremental pivots to address their causes. Regards, Alan
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
On Jan 21, 2015, at 3:39 AM, Benson Margulies bimargul...@gmail.com wrote: On Wed, Jan 21, 2015 at 4:03 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Jan 20, 2015 at 9:38 PM, Chris Douglas cdoug...@apache.org wrote: On Mon, Jan 19, 2015 at 11:57 PM, Bertrand Delacretaz bdelacre...@apache.org javascript:; wrote: How is that different from pruning the current IPMC membership by removing inactive members? Doing *that* would be straightforward. Take the set of mentors on currently incubating projects, add the other half dozen who review releases, and set everyone else to voluntary emeritus status. Done Agreed - but I don't see how that improves things anyway, I don't see any problem caused by those inactive members. The near-ad-hominem tone of this thread has extracted a reply in my own defense. It is a misunderstanding, verging on willful, to claim that the V2 proposal is primarily intended to remove either inactive or noisy persons from the group. it is a fabrication that there is any idea that some person other than the board might select an initial set of people to further some particular agenda. The idea here of the small group, extracted from something Ross wrote on the Wiki in 2013, is that an incubator committee doesn't need to be big and it doesn't need to grow via merit, if its only job is to accept the board's delegation of a limited set of supervisory tasks. If you make a smaller group, it might still contain vigorous disagreement, but on a scale where they can manageably reach consensus. It would think less of the board if they failed to select people likely to have some significant disagreements. I resent your and Chris’ characterization of this thread. All that’s been taking place is a frank and civil discussion of opinions as to what the implication of some proposals mean. Your, and Chris’, attempt to characterize them as taking on an ad-hominem tone suggest to me that we are poking at the Achilles heal of the Iv2 proposal and Chris’ impromptu proposal to fork the Incubator. At the heart of both there is a culling of IPMC members. Sure, the new IPMC may have Oscar Madison” and “Felix Ungar” tossed into the same bag but that’s a distraction from the real problem that I, and maybe Bertrand, are trying to point out. At the proposals' core is that there are IPMC members who want to participate but would be left out and in the end the “problems” with the Incubator would not be resolved since, as Chris accurately puts it, we will have distilled dysfunction. But is it dysfunctional? Only when it tries to be like a school of business and come up with new and improved processes for bringing in new projects instead of focusing on the core problems which don’t go away, tooling and mentor accountability. Otherwise, I think we do a pretty good job. We make mistakes, sure, but mistakes will always be made and I think we’ve made good, focused, incremental pivots to address their causes. Regards, Alan
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.)
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.)
On Jan 21, 2015, at 2:03 PM, Marvin Humphrey wrote: 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? Yes and that may be a call for more informed *action* by the IPMC. Like connecting with the mentors and podling to find out where the community is if anywhere. There may be no there there. Regards, Dave 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.)
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.)
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.
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.)
On Wed, Jan 21, 2015 at 4:03 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Jan 20, 2015 at 9:38 PM, Chris Douglas cdoug...@apache.org wrote: On Mon, Jan 19, 2015 at 11:57 PM, Bertrand Delacretaz bdelacre...@apache.org javascript:; wrote: How is that different from pruning the current IPMC membership by removing inactive members? Doing *that* would be straightforward. Take the set of mentors on currently incubating projects, add the other half dozen who review releases, and set everyone else to voluntary emeritus status. Done Agreed - but I don't see how that improves things anyway, I don't see any problem caused by those inactive members. The near-ad-hominem tone of this thread has extracted a reply in my own defense. It is a misunderstanding, verging on willful, to claim that the V2 proposal is primarily intended to remove either inactive or noisy persons from the group. it is a fabrication that there is any idea that some person other than the board might select an initial set of people to further some particular agenda. The idea here of the small group, extracted from something Ross wrote on the Wiki in 2013, is that an incubator committee doesn't need to be big and it doesn't need to grow via merit, if its only job is to accept the board's delegation of a limited set of supervisory tasks. If you make a smaller group, it might still contain vigorous disagreement, but on a scale where they can manageably reach consensus. It would think less of the board if they failed to select people likely to have some significant disagreements. -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: Next steps for various proposals (mentor re-boot, pTLP, etc.)
On Tue, Jan 20, 2015 at 9:38 PM, Chris Douglas cdoug...@apache.org wrote: On Mon, Jan 19, 2015 at 11:57 PM, Bertrand Delacretaz bdelacre...@apache.org javascript:; wrote: How is that different from pruning the current IPMC membership by removing inactive members? Doing *that* would be straightforward. Take the set of mentors on currently incubating projects, add the other half dozen who review releases, and set everyone else to voluntary emeritus status. Done Agreed - but I don't see how that improves things anyway, I don't see any problem caused by those inactive members. -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.)
On Jan 19, 2015, at 11:57 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Jan 20, 2015 at 1:37 AM, Chris Douglas cdoug...@apache.org wrote: ...So make a list of the IPMC members you believe should judge the other 90%, and submit a proposal to the board to start a new project. Fork the incubator How is that different from pruning the current IPMC membership by removing inactive members? I don't think those inactive folks are a problem, but if people think they are it's easy to ask them if they want to stay, and remove those who reply no or don't reply. No one is saying that the problem is inactive IPMC members. No one. 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”. Frankly, if there are IPMC members that are a real problem then it’s the job of the VP of the Incubator to have a “chat” with them. Are there really so many that it warrants a reboot of the IPMC itself? Regards, Alan
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: Next steps for various proposals (mentor re-boot, pTLP, etc.)
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 the board for their replacements, a very unmeritocratic suggestion that is quite surprising. It's not clear at all how the membership can address issues with this sub-board as they can with the Board. I think this proposal takes the likely outcome of the first proposal, that only a small core group of professional membership can manage sufficient activity as mentors to not be kicked from podlings, and codifies it with new structure and bylaws. Maybe in the end this is admitting reality. However, discussion of this proposal also floated the idea that the sub-board be later given authority to supervise the affairs of established TLPs, which is deeply problematic* and I suspect still hovers in the wings. I would hope not. 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 This doubles down on the aspect of the Strawman proposal where PPMC members are powerless to vote on releases. Here they are powerless to make any and all project management decisions about their own software they brought to Apache. It's not mentoring if you make all of the decisions for them. * - Find
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
On Jan 20, 2015, at 6:46 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: 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 ;-) I am not espousing a conspiracy theory; there is no secret cabal formed after an ApaceCon pub crawl. I too am being candid. I am merely providing an unvarnished distillation of what the proposals virtually are. Garnering consensus is difficult here, in part because of the fuzziness you mention, but also because members have such different opinions as to what the Incubator function is and what it means to be an Apache project. Under the above proposals, that necessarily messy, frustrating, exhausting, process of garnering consensus on the above thorny issues will not take place as philosophically compatible IPM v2 members turn out Apache projects that fit their view. - 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: Next steps for various proposals (mentor re-boot, pTLP, etc.)
On Tue, Jan 20, 2015 at 4:39 PM, Alan Cabrera l...@toolazydogs.com wrote: ...Under the above proposals, that necessarily messy, frustrating, exhausting, process of garnering consensus on the above thorny issues will not take place as philosophically compatible IPM v2 members turn out Apache projects that fit their view Ok, I see your point now. Another reason for fixing things that need to fix instead of blowing up the whole thing just to see if it lands in a better shape. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Next steps for various proposals (mentor re-boot, pTLP, etc.)
On Mon, Jan 19, 2015 at 11:57 PM, Bertrand Delacretaz bdelacre...@apache.org javascript:; wrote: How is that different from pruning the current IPMC membership by removing inactive members? Doing *that* would be straightforward. Take the set of mentors on currently incubating projects, add the other half dozen who review releases, and set everyone else to voluntary emeritus status. Done. The only thing people are taking from this discussion is offense. Allusions to problematic people or patterns- presented with too few details to refute- are coy nonsense. Contact the person(s) directly, raise it on private@ and fix it, or swallow your indignation and live with it. If some group thinks they're held back by the current project and they want to try something radically new, they should JFDI already and stop twisting in the wind. -C
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
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Ditto, kudos to ChrisD ++ 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: Monday, January 19, 2015 at 5:48 PM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.) On Mon, Jan 19, 2015 at 4:37 PM, Chris Douglas cdoug...@apache.org wrote: submit a proposal to the board to start a new project. Fork the incubator. Hmm... That is the first interesting variation here. - 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.)
I do not dispute anything written below nor do I intend this to be a last word, just a clarification. I n neither model are people powerless in any meaningful sense. I approached these proposals by putting myself in the shoes of a newcomer as best as I'm able (I've been PMC for years and PPMC also). The feeling of investment in the process I'd have would be different than before under the second two options (*not* the mentor reboot), as would be the calculus of bringing a project to Apache. I have not observed the IPMC model to take ownership away, because the initial contributors bringing their project here are formed into a PPMC of equals and the usual release votes done by the IPMC are up-or-down checks on releases, not exercises in differential power. On Mon, Jan 19, 2015 at 4:15 PM, Benson Margulies bimargul...@gmail.com wrote: I'm in the odd situation of not particularly wanting to argue in favor of the proposal I wrote, yet finding it hard to resist the provocation of messages that appear, to me, to misunderstand it. So I'll restrict myself to the following, and I won't reply to any further dispute. Anyone else is welcome to have a last-er word than me. The incubator is like no other Apache project. It is not a meritocratic, volunteer, community, producing a software product for the public good. It is a volunteer, meritocratic, group of people solving a problem for the board. The problem that the incubator sets out to solve is this: How do you bootstrap a community from scratch? Because it is a group of people solving a problem for the board, there's no special 'merit' in shaping it in the usual ASF PMC growing community mold. There may by some problems with that shape related to scale, noise, and responsibility. Some people who find those problems to be severe want to make changes. Others, not so much. The board is always free to solve any problem with any structure that it finds effective; there's no 'constitutional' requirement that everything is a meritocratic PMC. Witness what happened to ApacheCon. We have here two competing visions. The current vision says: Let people who have never run an Apache community it start doing it with coaching and supervision from 'mentors'. The alternative vision says, Start with a kernel of people who have done it before. Those of you who are happy with the current vision? Great! I wrote up the alternative vision to try to put some clarity onto a lot of prior writing that found fault with the current model and looked for an alternative. I n neither model are people powerless in any meaningful sense. In the current model, people have an interaction with the full IPMC. They can get pretty frustrated, but, as Mavin has documented, the frustration is more the fault of the lack of documentation than of the behavior of the IPMC. In the alternative model, they _start out_ with a group of 'strangers' at the center of their community, but those strangers are chosen specifically for their ability and experience in building a consensus community. And, in any case, they they will rapidly become an ever-smaller fraction of the group. Badly-behaved mentors (and other IPMC members) can overbear in the current model, and badly-behaved seed-PMC members could overbear in the alternative. I very much doubt that email discussion will yield any consensus to do anything radical. Which might be fine. When the time comes to find Roman's successor, an interesting situation may arise in which candidates might declare their intention to implement changes. And just to be clear, _I_ am not running on the platform of implementing what I wrote -- or any other way. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
I'm in the odd situation of not particularly wanting to argue in favor of the proposal I wrote, yet finding it hard to resist the provocation of messages that appear, to me, to misunderstand it. So I'll restrict myself to the following, and I won't reply to any further dispute. Anyone else is welcome to have a last-er word than me. The incubator is like no other Apache project. It is not a meritocratic, volunteer, community, producing a software product for the public good. It is a volunteer, meritocratic, group of people solving a problem for the board. The problem that the incubator sets out to solve is this: How do you bootstrap a community from scratch? Because it is a group of people solving a problem for the board, there's no special 'merit' in shaping it in the usual ASF PMC growing community mold. There may by some problems with that shape related to scale, noise, and responsibility. Some people who find those problems to be severe want to make changes. Others, not so much. The board is always free to solve any problem with any structure that it finds effective; there's no 'constitutional' requirement that everything is a meritocratic PMC. Witness what happened to ApacheCon. We have here two competing visions. The current vision says: Let people who have never run an Apache community it start doing it with coaching and supervision from 'mentors'. The alternative vision says, Start with a kernel of people who have done it before. Those of you who are happy with the current vision? Great! I wrote up the alternative vision to try to put some clarity onto a lot of prior writing that found fault with the current model and looked for an alternative. In neither model are people powerless in any meaningful sense. In the current model, people have an interaction with the full IPMC. They can get pretty frustrated, but, as Mavin has documented, the frustration is more the fault of the lack of documentation than of the behavior of the IPMC. In the alternative model, they _start out_ with a group of 'strangers' at the center of their community, but those strangers are chosen specifically for their ability and experience in building a consensus community. And, in any case, they they will rapidly become an ever-smaller fraction of the group. Badly-behaved mentors (and other IPMC members) can overbear in the current model, and badly-behaved seed-PMC members could overbear in the alternative. I very much doubt that email discussion will yield any consensus to do anything radical. Which might be fine. When the time comes to find Roman's successor, an interesting situation may arise in which candidates might declare their intention to implement changes. And just to be clear, _I_ am not running on the platform of implementing what I wrote -- or any other way. - 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.)
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 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 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 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 the board for their replacements, a very unmeritocratic suggestion that is quite surprising. It's not clear at all how the membership can address issues with this sub-board as they can with the Board. I think this proposal takes the likely outcome of the first proposal, that only a small core group of professional membership can manage sufficient activity as mentors to not be kicked from podlings, and codifies it with new structure and bylaws. Maybe in the end this is admitting reality. However, discussion of this proposal also floated the idea that the sub-board be later given authority to supervise the affairs of established TLPs, which is deeply problematic* and I suspect still hovers in the wings. I would hope not. 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 This doubles down on the aspect of the Strawman proposal where PPMC members are powerless to vote on releases. Here they are powerless to make any and all project management decisions about their own software they brought to Apache. It's not mentoring if you make all of the decisions for them. * - Find me any PMC of any TLP that would welcome the self-introduction of newly empowered meddlers who by definition are uninformed of their project particulars. now has the feedback gathering section at the end. I am done with my personal feedback. Please provide yours. Here's the criteria you can apply when deciding whether to spend time on this or not: imagine that the proposal the way it is written were to come to a vote. If at that point you'd be inclined to vote -1 -- please let us know NOW. Using a VOTE thread as a forcing function for folks to
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
I agree with Andrew. Creating a sub-board of the most vocal members of the IPMC distills its dysfunction. But this doesn't require consensus. The proposals focus on identifying the true members of the IPMC; clearly, the authors believe themselves to be among the elect. So make a list of the IPMC members you believe should judge the other 90%, and submit a proposal to the board to start a new project. Fork the incubator. If the board is interested in your proposal, then you can demonstrate how successful a small, committed group can be in contrast to the 150+ member IPMC. Concurrently, others may propose TLPs directly to the board, and this committee will continue as-is. Surely all of you have better things to do than... this. -C On Mon, 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 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 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 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 the board for their replacements, a very unmeritocratic suggestion that is quite surprising. It's not clear at all how the membership can address issues with this sub-board as they can with the Board. I think this proposal takes the likely outcome of the first proposal, that only a small core group of professional membership can manage sufficient activity as mentors to not be kicked from podlings, and codifies it with new structure and bylaws. Maybe in the end this is admitting reality. However, discussion of this proposal also floated the idea that the sub-board be later given authority to supervise the affairs of established TLPs, which is deeply problematic* and I suspect still hovers in the wings. I would hope not. 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 This doubles
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
On Tue, Jan 20, 2015 at 1:37 AM, Chris Douglas cdoug...@apache.org wrote: ...So make a list of the IPMC members you believe should judge the other 90%, and submit a proposal to the board to start a new project. Fork the incubator How is that different from pruning the current IPMC membership by removing inactive members? I don't think those inactive folks are a problem, but if people think they are it's easy to ask them if they want to stay, and remove those who reply no or don't reply. -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.)
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 https://wiki.apache.org/incubator/Strawman https://wiki.apache.org/incubator/IncubatorV2 now has the feedback gathering section at the end. I am done with my personal feedback. Please provide yours. Here's the criteria you can apply when deciding whether to spend time on this or not: imagine that the proposal the way it is written were to come to a vote. If at that point you'd be inclined to vote -1 -- please let us know NOW. Using a VOTE thread as a forcing function for folks to provide feedback would be *really* unfortunate. Also, please try to keep 'deal breakers' section as small as possible (pushing all the non-critical piece of your feedback to the 'suggestions' section). When in doubt (even if it is -0) -- make it go to suggestions. The only items that belong to 'dealbreakers' are the ones that would *strongly* motivate you to vote -1 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.)
On Fri, 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). As a matter of fact, while editing yours (sorry, I took the liberty) and leaving feedback for Alan's I felt like they were pretty close in spirit, with yours going all the way to make podlings behave as close to TLPs as possible while still not overwhelming the board. 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. That's the plan. 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.)
On Sat, Jan 17, 2015 at 12:16 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: http://wiki.apache.org/incubator/IncubatorIssues2013 If someone reviews this it would be nice to add brief comments about today's state, maybe right after each item's title (like early 2014 status: still a problem) -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.)
On Mon, Jan 19, 2015 at 2:59 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Sat, Jan 17, 2015 at 12:16 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: http://wiki.apache.org/incubator/IncubatorIssues2013 If someone reviews this it would be nice to add brief comments about today's state, maybe right after each item's title (like early 2014 status: still a problem) First of all, this appears to be an immutable page. That said, looking at the list of issues, I'd say that every one of them still applies (the caveat being: to what degree) although the analysis suggestions could be slightly out of date. In general, I'd split the issues in two categories: Operational/Structural issues Issue 01 - lack of mentor participation Issue 02 - lack of progress towards graduation Issue 03 - Too many cooks spoil the IPMC broth Issue 04 - Horrible signal-to-noise ratio on general@a.o for podling contributors Issue 05 - Inadequate reporting Issue 07 - Vetting releases is a huge pain Issue 08 - The IPMC is broken Documentation: Issue 06 - Podlings status metadata is not reliable Issue 09 - People do not follow through to improve Incubator documentation Issue 10 - Steps for Podlings to Acquire Resources Are Disparate and Poorly Documented Issue 11 - Clearly and concisely document the principles and constraints for the ASF Issue 12 - Cold welcome for new projects In my view, the two categories can be addressed in parallel. The Documentation agenda seems to be passionately championed by Marvin and a few other folks. I'd expect them to make quite a bit of progress there. Personally, I'd like to focus this thread on the first category. 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.)
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
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: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Roman, Are all three available on the wiki? Maybe link to them just in case I missed one.. John On Wed Jan 14 2015 at 11:48:41 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? Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
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.)
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.)
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: Next steps for various proposals (mentor re-boot, pTLP, etc.)
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: 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: Various
Hani writes: I'm fairly astounded by the amount of email generated due to my name being on the initial committer list. I am perplexed that you feel that a dislike of an Apache project merits a membership rejection though. and I am not aware of any Apache membership requirements that state that one's freedom of speech and expression are curtailed in any way Just to be clear: being a committer on a Incubated project or even a real ASF project is totally and completely a different beast than being a member of the ASF. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Various
On Jun 23, 2006, at 12:52 AM, Hani Suleiman wrote: If Apache people feel that my technical abilities are not relevant, and that what should matter in whether I am allowed in as a cxfire committer is how willing I am to tow the party line, then I shouldn't be on that list. Apache would be the first organisation I've joined (or might have joined) that did not judge me on technical merit; quite an irony considering the whole meritocracy approach that Apache claims. This is, astoundingly, my first experience of being judged not on technical merit, but on random blathering that serves no particular purpose than ranting for ranting's sake. To be honest, technical merit counts not a bit, if the person is so disruptive to the community as to stagnate or destroy the communal, collaborative nature central to the ASF. So, to be blunt, we would prefer someone with adequate skills who gets along with people and works well with people rather than a top-notch code monkey who is a super prick. And no, I'm not implying that you are one of those at all. Just making a point. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Various
On Fri, 2006-06-23 at 05:52 +0100, Hani Suleiman wrote: It is interesting to note that all the people who have objected are those who feel personally offended by some of my writing (specifically, the tomcat and axis2 rants...ironically my tomcat I was never personally offended by your rants. However, I was very impressed by what it shows about you as a person. I'm sorry that you can't take a little criticism, and while I will happily admit that yes, I did insult you in ways that you probably didn't quite expect, I fully stand by everything I said, and will still insist that Axis2 and Tomcat are awful projects, that are badly written and have only gotten where they are today due to marketing forces, instead of technical merit. Thanks for clarifying this- several people have said on this list that your blog is simply a public persona and that you don't really believe in what you write there. Your statement shows that they don't know you as well as they thought they did! I am perplexed that you feel that a dislike of an Apache project merits a membership rejection though. Does everyone at Apache love every project there? If that were the case, then the whole ecosystem is in a far unhealthier state than anyone on the outside might suspect. Who said anything about loving every project? Apache is fundamentally about communities and not about code. It doesn't matter whether I or any other ASF person likes the technical rationale/motivation/aspects of the project or not- as long as a healthy community exists for it then its a great project from ASF's perspective. That project may produce software for underwater basketweaving, but the ASF doesn't worry about the technical merits of such software. I believe in cxfire, and think it's a superb project. I think competition in this space is healthy, and think it's rather lame that people like dims and sanjiva keep trying to cast doubts on the validity of the project, just because it happens to eat into their projected revenues. Coming from a guy who loves to dish out criticism, how come you can't take a bit of it? The casting doubt was to understand what it is .. the proposal talks about SOA etc. etc. and James, one of the mentors, says SOA means nothing (paraphrased) and the different people give different explanations of what it is. If the people who proposed the project don't quite agree what it is, how do you expect to form a healthy community? Here's what I wrote to James' explanation of what it is: On Thu, 2006-06-22 at 17:30 +0200, James Strachan wrote: CeltixFire is aimed at implementing the JAX-WS/JAX-WSA/JSR-181 standards which are the newer standards for working with SOAP WS-Addressing on the Java platform Thanks for the clarification. So its basically an alternate to Axis2 as we are working on all these specs there too; which of course is cool .. alternates are a good way to figure out different ways of skinning a cat and eventually we'll find the right way (hopefully before the cat dies ;-)). Where is there anything there saying Apache doesn't accept alternatives? Or where does it say that I objected to it? If its an alternate to Axis2, then I'm glad to +1 it. It does feel like there's a small amount of hypocrisy going around, where people express concern that cxfire has many IONA people involved, without noticing that most of the objectors are WSO2 people, who (quite rationally) put WSO2 priorities ahead of Apache ones. Instead of looking at where people are employed why don't you look at what we do in Apache and why that gives us the credibility to ask these questions? I've been contributing to Apache since 1998, when I wrote the extension code for Xalan, using then IBM BSF, which also I created. BSF is of course now an Apache project. I was the one who created Apache SOAP originally (along with Matt Duftler from my group in IBM). I've participated in numerous WS projects and created the Axis2 effort long before WSO2 was even conceived. I doubt you can find a *single* place where I've let WSO2 priorities come in front of ASF ones. Paul has been involved since about 2001, when the WSIF project was donated to Apache by IBM. Paul is now a leading contributor to Synapse. Dims has been around since I don't know when .. before me too I believe (in Cocoon) and he is of course chair of the WS PMC, which is a position he earned by his long and solid contributions to WS projects. Again, he got to that position before WSO2 was ever conceived. We have all *earned* the right to question what these new projects are how they should or should not be brought into the ASF. If there's a policy of only endorsing one technology for any given field within Apache, then sure, cxfire does not belong. If there is space for allowing competing technologies, then I fail to see why xfire choosing to ignore axis2 or not support it has any relevant at all as to
Re: Various
Hani, (I'm a big BileBlog fan. I'm ever so upset that Geir always gets named when it comes to Harmony while I and more importantly quite a few others also pour lots of effort in too. I did a lightning talk at ApacheCon Las Vegas titled The ASF sucks. I had 5 minutes, I could've gone on for 30. Lots of fun. I think most people liked it. I'm a committer and member and things like that around here. Most people around here appreciate some good roasting or bile as much as the next person.) On Fri, Jun 23, 2006 at 05:52:51AM +0100, Hani Suleiman wrote: I'm fairly astounded by the amount of email generated due to my name being on the initial committer list. I would say I was a little surprised. This e-mail of yours is also a bit of a surprise though. Nevertheless. To respond to this actual email. www.apache.org says The Apache projects are characterized by a collaborative, consensus based development process, an open and pragmatic software license, and a desire to create high quality software that leads the way in its field. We consider ourselves not simply a group of projects sharing a server, but rather a community of developers and users. Some of the keywords there relevant to this thread are collaborative and community. We expect many simple things from each other such as * showing respect for your peers * making sure your e-mails to apache mailing lists are PG-13 and preferably suitable for all ages * not making unfounded assertions * never flaming other people, especially not in public * no trolling or flaming in general Being frank and undiplomatic is fine. I'm frank and undiplomatic all the time. Saying some piece of software is bad is fine (if backed up by technical argument or reference). For example if I mention that I think that SOAP is a bad idea in the first place (I do) and that I think that all implementations of it today all have rather serious problems (for example, scalability is simply still a joke. 50 than 3 requests per second is still abonimable. I want 5000, and mind you, when running on my laptop), that is fine. But e-mails like this one basically do fit the 20-year-old textbook definitions of trolling and flaming that the usenet people invented way back. I won't bother picking it apart to point this out, I'm rather confident you know exactly what I mean. Being frank and undiplomatic again, we don't have all that many people around here who repeatedly display that kind of behaviour on apache mailing lists, and that's not about to change. Now, could we please get back to more interesting things? LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Various
Hi Leo, On Jun 23, 2006, at 10:41 AM, Leo Simons wrote: The Apache projects are characterized by a collaborative, consensus based development process, an open and pragmatic software license, and a desire to create high quality software that leads the way in its field. We consider ourselves not simply a group of projects sharing a server, but rather a community of developers and users. Some of the keywords there relevant to this thread are collaborative and community. We expect many simple things from each other such as * showing respect for your peers * making sure your e-mails to apache mailing lists are PG-13 and preferably suitable for all ages * not making unfounded assertions * never flaming other people, especially not in public * no trolling or flaming in general Yep, and I think in every technical context (and by that I mean any community I'm part of, whether it be the JCP, Opensymphony, a bunch of java.net projects, and so on) I've always adhered to every single one of these rules, or promptly apologised if I'd ever stepped over the line. The only venue that's an exception to these rules of good behaviour is my blog, and that will remain an exception. I apologise if my email came off to harshly, that was certainly not my intent. It was bourne out of frustration from (for the first time) seeing people judge me based on a blog I write for fun, that is it in any way tied or or relevant to what I do *professionally*. Perhaps I should have been clearer when I said 'technical', and made it obvious that it's not just about the code, or how good (or bad) of a developer I am, it's about how I function in mailing lists, how I am towards people asking for help, and whether I play nice in whatever ecosystem I'm in. ALL those to me count as professional environments, where unprofessional behaviour will be weeded out very quickly. The bileblog is what it is, and will remain what it is. My behavior in other situations similar to the current one (ie, being part of a community) is what should be under scrutiny, not what I choose to do in my spare time. Anyway, as flattering it is to be the subject of so much attention, I think it's more worthwhile to instead focus on cxfire and question its merit, than on some random committer who does weird things in his spare time! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Various
Craig McClanahan wrote: PS: Hani, will you *please* someday, just once, spell my name correctly so that Google can find your pearls of wisdom about me? :-) :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Various
Hani. I haven't read your bileblog, but this email really shows a bad attitude. I personally don't care how good your code is. in my past experience your code isn't worth the pain the attitude is going to cause. Technical merit is only aspect of apache, it's about the community. and flamewars are so 90's it isn't funny. as for party line, you don't have to tow anything.. you just need to give other apache comitters / members some respect. as for saying Apache Sucks.. go for it. just be constructive about it (and be prepared to help un-suckify it.. any moron can say something is bad) --Ian On 23/06/2006, at 2:52 PM, Hani Suleiman wrote: I'm fairly astounded by the amount of email generated due to my name being on the initial committer list. It is interesting to note that all the people who have objected are those who feel personally offended by some of my writing (specifically, the tomcat and axis2 rants...ironically my tomcat DefaultServlet rant was purely technical and did not degenerate into my usual personal insult comfort zone). I'm sorry that you can't take a little criticism, and while I will happily admit that yes, I did insult you in ways that you probably didn't quite expect, I fully stand by everything I said, and will still insist that Axis2 and Tomcat are awful projects, that are badly written and have only gotten where they are today due to marketing forces, instead of technical merit. I am perplexed that you feel that a dislike of an Apache project merits a membership rejection though. Does everyone at Apache love every project there? If that were the case, then the whole ecosystem is in a far unhealthier state than anyone on the outside might suspect. If Apache people feel that my technical abilities are not relevant, and that what should matter in whether I am allowed in as a cxfire committer is how willing I am to tow the party line, then I shouldn't be on that list. Apache would be the first organisation I've joined (or might have joined) that did not judge me on technical merit; quite an irony considering the whole meritocracy approach that Apache claims. This is, astoundingly, my first experience of being judged not on technical merit, but on random blathering that serves no particular purpose than ranting for ranting's sake. Just to set expectations, I will not stop saying things like 'Apache sucks', because I still do think that many of the processes and members have some terrible flaws. I am not aware of any Apache membership requirements that state that one's freedom of speech and expression are curtailed in any way; it is after all an alleged meritocracy, all that matters is how good the code I check in is, and how well I play within the team I'm a member of. If the cxfire team at any point feels I'm a liability rather than an asset, I would gladly leave. In fact I'd like to think that I'm self-aware enough to leave way before they feel the need to ask me to. I know plenty of Apache members who find many of the processes cumbersome and onerous, yet are still active participants; nobody seems to threaten them with being kicked out. I believe in cxfire, and think it's a superb project. I think competition in this space is healthy, and think it's rather lame that people like dims and sanjiva keep trying to cast doubts on the validity of the project, just because it happens to eat into their projected revenues. It does feel like there's a small amount of hypocrisy going around, where people express concern that cxfire has many IONA people involved, without noticing that most of the objectors are WSO2 people, who (quite rationally) put WSO2 priorities ahead of Apache ones. If there's a policy of only endorsing one technology for any given field within Apache, then sure, cxfire does not belong. If there is space for allowing competing technologies, then I fail to see why xfire choosing to ignore axis2 or not support it has any relevant at all as to whether it can live in Apache or not. I always thought that despite all its flaws, Apache was a great ground for the 'let a thousand flowers bloom' approach, and I am frankly disturbed by how much say commercial interests seem to have in whether projects get accepted or not. In many ways this thread has left me with an even worse impression of Apache than I already had, which is, believe or not, a very sad thing. I'd like to think that Apache is a meritocracy, driven by technology, with no allegiance to commercial interests. It is driven by the concept of open source for the sake of open source; not open source that we can now build a company around and get funding and piss around with in order to make a living to avoid having a real job. Certainly not the latter to the exclusion of the former! On that basis, I cannot conceive of a single good reason for rejecting cxfire. By all criteria
