I like this general direction as well; seems much more manageable. +1. Karl
On Thu, Feb 2, 2012 at 6:52 PM, Leo Simons <m...@leosimons.com> wrote: > Hey folks, > > I just wanted to chime in with a +1 for the general direction. I think > there's actually a lot of work to do to iron out how to reorganize > things. Before digging in, I suggest we abstract out a little bit to > see if we have consensus on the overall goals and desired end state > before starting to debate the details, or the process by which to get > there. > > 1) There are people who produce guides, rules and policy that describe > the incubation process. These rules are then imposed on other groups > at apache by board decree. > 2) At any point in time, there shall be many groups of people > following the incubation process. > 3) There is a mechanism in place to provide oversight over all the > different ongoing incubations. > 4) The differences between communities going through incubation and > those that aren't is clear and understood by all (including end users, > press, etc). > > I think the above invariants describe both incubation as of yesterday > and incubation as of tomorrow. But, we have some issues with the > current incubator. > > a) The volume of incubation activity has grown such that oversight is > difficult. > b) Large group sizes (particularly general@ and IPMC roster) make > accountability and consensus-building difficult. > c) meritocracy is hampered by having the people doing the work not > having binding votes on their own work. > d) ... <<add your own similar issues>> ... > > The basic realization is that combining all the people from 1) and 2) > into effectively one big group [1] is no longer the best idea. > > So, we want to redesign how we organize into groups, and associated > with that we want to tune our oversight mechanisms. > > The basic idea is to split the current single really big group that is > the incubator into smaller groups that still cooperate and discuss and > whatnot, but are accountable and overseen separately. These smaller > groups become their own committees with their own VPs that report to > the Board. > > Is that a reasonable re-statement of the abstract idea? Is that > something we can all get behind? > > The next steps then involve deciding just how to split things up. > Since I'm off to go skiing tomorrow I won't be around next week to > participate in the details of all that. Have fun :-) > > cheerio, > > Leo > > [1] the choice of the vague term 'group' is intentional: give us some > degrees of freedom to design the structure, in a formal *and* an > informal sense. One kind of group is a PMC, but there's also another > kind of group which is "people subscribed to a mailing list" and > another one "people that read the stuff that's on the mailing list" > and another which is "people who feel responsible for what's going on > on that mailing list", etc. > > On Wed, Feb 1, 2012 at 11:25 PM, William A. Rowe Jr. <wr...@apache.org> wrote: >> On 1/31/2012 5:05 PM, Mattmann, Chris A (388J) wrote: >>> >>> On Jan 31, 2012, at 1:28 PM, Roy T. Fielding wrote: >>>> >>>> Having said that, I should note that the context of Incubator is >>>> significantly different than a normal PMC. If incubator wants to structure >>>> itself more like a board and less like a project, I really don't have >>>> much to say against that. Note that it should effect all of the decision >>>> guidelines that give veto power, not just personnel decisions. >>> >>> Isn't that the problem right now though? Like it or not, the Incubator PMC >>> has evolved into a mini-board, in the worse sense of the word. You guys >>> have a monthly meeting via telecon; an agenda; a set of action items, and >>> you still don't get everything that you want to get done, done. >>> >>> A very small percentage of folks within the IPMC actually maintain that type >>> of board-like oversight over its podlings. And thus, because of that, the >>> more >>> I think about it, quite honestly, I don't know what the Incubator PMC is >>> doing >>> other than delay the inveitable eventuality that many of these projects will >>> graduate and become TLPs and thus "the board's problem"; whereas many >>> of them will not graduate, and become "not Apache's problem". We have an >>> Attic for projects that make it to TLP for that. Heck, we have SVN and could >>> even reboot Incubator dead projects if a group of individuals came along >>> and wanted to maintain the code. >>> >>> My conclusion from all the ruckus recently has been that the Incubator "PMC" >>> is nothing more than an Incubator "mailing list" where many ASF veterans >>> and those that care about the foundation discuss (and sometimes argue) >>> about the foundation's policies and interpretations of law that not even >>> lawyers >>> are perfect at -- we're all human yet we try and get on our high horse here >>> and act like we speak in absolutes and the will of one or a small subset is >>> the will of the many when we all know that in the end, if it's not fun >>> anymore, >>> we wouldn't be here. >>> >>> What would be so bad about saying that the Incubator, over its existence, >>> has served its purpose and has devolved into an umbrella project of the type >>> that we are looking to get rid of at the Foundation. I agree with Bill on >>> the >>> perspective that I'm sure at some point (and it's probably already >>> happened), >>> we will experience Jakarta type symptoms and potentially may go down that >>> road. Instead of couching it as "scary HUGE" change that several Apache >>> vets have expressed to me that the Foundation doesn't like, how about we >>> don't call it a "change" at all; and simply a "success". IOW, the Incubator >>> itself >>> has "graduated" and it's time for it to be "Attic'ed". >>> >>> In replacement, I propose the following concrete actions: >>> >>> 1. Move the Incubator process/policy/documentation, etc., to ComDev - I >>> agree with gstein on this. I think it could be maintained by the ASF >>> community >>> folks there, and updated over time. But it's not vastly or rapidly changing >>> really >>> anymore. >>> >>> 2. Discharge the Incubator PMC and the role of Incubator VP -- pat everyone >>> on >>> the back, go have a beer, watch the big game together, whatever. Call it a >>> success, not a failure. >>> >>> 3. Suggest at the board level that an Incubation "process" still exists at >>> Apache, >>> in the same way that it exists today. New projects write a proposal, the >>> proposal >>> is VOTEd on by the board at the board's next monthly meeting, and those >>> that cannot be are QUEUED for the next meeting, or VOTEd on during out of >>> board inbetween time on board@. Refer those wanting to "Incubate" at Apache >>> to the existing Incubator documentation maintained by the ComDev community. >>> Tell them to ask questions there, about the process, about what to do, or if >>> ideas make sense. But *not* to VOTE on whether they are accepted or not. >>> >>> 4. Require every podling to have at least 3 ASF members on it, similar to >>> the >>> current Incubator process. >>> >>> 5. Operate podlings *exactly the same* as a TLP. There is a chair. There is >>> a >>> committee. Committee members have binding VOTEs on releases. >>> >>> I'm sure folks will argue this is blasphemy or that it will just add to the >>> board's >>> work, or that .... I'm ugly ... whatever. The fact of the matter is we kick >>> spinning >>> around in circle's trying to fix process issues that have been band-aided >>> for >>> years and that are now leaking like a sieve whenever we decide it's time to >>> shine a light on them. When things are going "well" in the Incubator, it's >>> not >>> because they are well. It's because no one is asking questions and they've >>> chosen to ignore some of the gaping holes on the poor wounded body that >>> remains. And then when some folks go and point out the gaping holes, we >>> get these huge song and dances that don't amount to anything other than >>> the old mantra "incremental change; don't rock the boat too much; XXX board >>> member won't go for it; not here at Apache". Whatever. >>> >>> I think the board knows there is an issue with the Incubator. A lot of IPMC >>> members do too. Some of us have spoken up; others haven't. I present >>> above what I feel are concrete steps that could be actioned upon that >>> I believe would improve the overall process and bring to light what is >>> already occuring: >>> >>> 1. podlings are themselves distinct communities and will interpret our >>> human laws and Apache doctrine the same as any other human when you >>> put 10 of them in a room -- in 10 different ways. >>> >>> 2. podlings are more and more able to pick up on the basic principles of >>> the Incubator documentation; its legal oversight and its processes. They >>> aren't perfect, but neither are any of us. It's pretty good and we've got >>> plenty >>> of RMs (as evidenced by other discussions) that can produce an Apache >>> release that hasn't gotten us sued yet. >>> >>> 3. mentors encourage their podlings to operate autonomously. general@ is >>> often labeled "the wild west" and for good reason. If I went over to HTTPD >>> and started spewing my OODT nonsense, many of you would scream foul >>> and blasphemy just like I'd do if you guys came over into OODT and started >>> flexing "your specific interpretations" of our commonly agreed upon mantra. >>> That's what general@ is like. I don't think it makes sense, and I think >>> those >>> mentors who are doing a good job on their projects and those projects >>> that are doing well would do well the same as TLPs. Many of the other >>> side conversations around this issue are suggesting that -- why nominate >>> folks for the IPMC when we could simply graduate the podlings? >>> >>> Anyways I could type more but I think I've beat this horse to death. I >>> appeal >>> to you and to the rest of the board members reading this thread will >>> consider >>> my proposal. Thanks for reading. >>> >>> --Chris, who I'll note *does* care about the IPMC and *does* care a ton >>> about Apache >>> and the folks here and our hallowed status as an awesome open source >>> organization. >> >> Giving this thread all due consideration, with its own subject; >> >> I'd modify your proposal just a smidge. Keep an Incubator VP with a very >> small >> operational committee just to help move the podling through the entire >> process >> of wrangling the necessary proposal, votes and board resolutions. Some >> amount >> of process documentation would remain under that VP and their committee. >> >> Take "VP, Project Incubation" out of the role of judging incoming or >> graduating >> projects. Leave general@ for the process of submitting a proposal to come in >> as an incubating podling or leave by way of graduation, the attic, or >> graveyard >> (full purge in the rare case of questionable IP provenience). >> >> Make every podling a proper PMC to include its mentors. Make a choice >> between >> including all listed initial contributors, or instead, have the mentors >> promote >> the actual contributors given time and merit, based on a well thought out and >> somewhat predictable flowchart. >> >> Have ComDev drive the effort to ensure all projects are nurtured by finding >> new >> mentorship of old, graduated projects as well as incubating projects who had >> lost >> their mentors. This might avoid some cases of the board imposing a full PMC >> reset >> on established projects. >> >> Most importantly, have the voting by the full membership on general@ to >> recommend >> to the board accepting a podling or graduating a podling to a TLP. Why? >> Given >> the example of the hotly contested AOO podling, if the membership >> (represented >> by Incubator PMC members) did not ultimately have the discussion that was >> held, >> and if the board had 'imposed' accepting AOO on the foundation, it would have >> done internal harm. Now maybe only 50 of the members care to review >> proposals >> and cast such votes. That's OK, they are still representative of the >> membership. >> If a member wants to gripe on the member's private list, they can be gently >> but >> emphatically nudged to take their concerns to the general@ discussion of the >> proposed project. >> >> In short, all incoming projects continue into an "Incubation" phase as we all >> understand it, subject to additional scrutiny and oversight by a collection >> of mentors and additional scrutiny by the board, reflected in their monthly >> and then quarterly report. A scorecard continues for the incubating projects >> of the milestones they must reach to graduate into a full fledged project. >> And we can even continue to restrict them to an incubation.apache.org domain >> until they reach that milestone. >> >> But they are plugged in from day one into the same array of services offered >> by Board/Legal/Infrastructure/Press/Trademarks/ComDev/ConCom with mentors to >> help them navigate. Beyond VP, Project Incubation, we will probably uncover >> other obvious services that the ASF should provide as a VP or committee of >> peers to nurture incoming podlings into successful, healthy projects. >> >> Every previous restriction on incubating podlings has been eliminated over >> the past 8 years. There is no reason to continue the incubator committee >> as an ombudsman, when every issue that applies to each incubating podling >> simultaneously applies to each established project. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
