incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <daddy...@gmail.com>
Subject Re: Incubator, or "Incubation"?
Date Fri, 03 Feb 2012 00:43:03 GMT
I like this general direction as well; seems much more manageable.  +1.
Karl

On Thu, Feb 2, 2012 at 6:52 PM, Leo Simons <mail@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. <wrowe@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-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message