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
