stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ant elder <>
Subject Re: [DISCUSS] probationary TLP experiment
Date Tue, 30 Jul 2013 13:38:59 GMT
Hi, yes sorry for not progressing this yet, i've been busy and then away on
holiday. Back now so i'll go resfresh my memory of all the previous emails
on the topic.


On Sun, Jul 21, 2013 at 7:04 AM, Sanjiva Weerawarana <>wrote:

> I'm happy to drive the proposal .. can we do it on dev@? I'm not on the
> If so, Ant, lets catch up a bit one of these so we can start a Wiki
> proposal. Maybe target August board meeting at this point?
> Sanjiva.
> On Sun, Jul 21, 2013 at 10:40 AM, Ross Gardler <
> > wrote:
>>  There needs to be a concrete proposal from this PPMC and its mentors,
>> so no we are not on track.
>> However, Ant did mail me offlist a few days ago to let me know he's been
>> swamped but does plan to get to this soon.
>> Of course the discussion doesn't need to be led by Ant.
>> Ross
>> Sent from my Windows Phone
>>  ------------------------------
>> From: Sanjiva Weerawarana <>
>> Sent: 7/20/2013 9:30 PM
>> To: dev <>
>> Subject: Re: [DISCUSS] probationary TLP experiment
>> Looks like there was no follow-up to this. Ross are you still on track to
>> put this forward?
>> Sanjiva.
>> On Mon, Jun 24, 2013 at 7:59 PM, Ross Gardler <
>> > wrote:
>>> During the proposal phase for the Stratos podling I floated the idea of
>>> the IPMC using the podling to experiment with a more streamlined incubation
>>> process.
>>> It is not my intention to drive this experiment. Ant Elder expressed a
>>> desire to explore the idea during recent discussions among the IPMC. Whilst
>>> we were drawing up the Stratos proposal I asked Ant if he would be willing
>>> to lead the experiment. He agreed.
>>> In this mail I will summarize the relevant parts of the discussion
>>> thread on the list. The intention is to
>>> give Ant a starting point for the discussions here. It's up to the Stratos
>>> community to ensure the experiement does not limit the project in any way
>>> and up to Ant to drive the experiment for the IPMC. Naturally, the IPMC
>>> mentors will be a very important part of defining the model and feeding
>>> back on the experiment to the IPMC. I'll be lad to help evaluate as an IPMC
>>> member too.
>>> Chris' original skeleton proposal is at [1]. This outlines who is
>>> responsible for what in the new model. I'll remind the team that the board
>>> has not discussed the proposals here and a number of board members have
>>> expressed concern about it, while a couple are actively pushing for it.
>>> The following specific questions were raised during discussions. These
>>> will need to be addressed in any proposal.
>>> # Who's responsible for monitoring the probation, the IPMC or the board?
>>> This is perhaps the biggest potential area for pushback is moving
>>> oversight for the project to the board. Going to board certainly bypasses
>>> the problem of the IPMC often getting in the way of efficient process but
>>> it also removes the valuable input that some members of the IPMC often
>>> provide. Furthermore, should there be a problem it means it is the board
>>> that must fix the problem. Podling mentoring is not, traditionally, a role
>>> the board has ever taken on (fixing broken communities is not the same as
>>> mentoring fledgling communities).
>>> Note that one Director explicitly stated that he will vote -1 on any
>>> proposal that has a "podling" reporting directly to the board. This doesn't
>>> mean it won't be approved by the board, but it does mean it will be
>>> rigorously discussed.
>>> # What bits must absolutely be done before probation begins?
>>> We dodged this question in the discussion thread  by saying we'd go to
>>> podling status first. I guess defining this is part of defining the scope
>>> of the experiment.
>>> # What minimum criteria does a probationary TLP have to meet to stay in
>>> good graces?
>>> Here I suggested the criteria would be the same as a TLP. The problem is
>>> understanding whether we have that documented anywhere. The IPMC has
>>> addiitonal requirements (e.g. keep the meta-data up-to-date) whilst the
>>> board has, for the last 12 months or so, been pushing to have TLPs provide
>>> some of the same meta-data (e.g. last release date, last committer
>>> addition, last PMC addition).
>>> I suggest trying to come up with using the same criteria for TLPs,
>>> podlings and pTLPs. Where podlings will have a lower set f expectations
>>> (i.e. no need to have voted in any committers yet, pTLPs have voted in a
>>> committer in the last six months but may not have done an approved release
>>> and TLPs should have a fairly regular flow of committers and releases).
>>> Note these "metrics" ought not be fixed, they should be seen as guidelines.
>>> A project with no recent releases that continues to report and answer user
>>> queries may just be mature, for example.
>>> One measure can be the pTLP PMC membership. Initially it would be only
>>> the project mentors and champion. Over time active committers from the
>>> initial committer list are voted into the PMC (recognising merit). So we
>>> then have a possible measure, if there are 3 members of the pTLP from the
>>> initial committer list then there are now sufficient binding votes for the
>>> project to operate as a TLP.
>>> While writing this I realised that we might want to propose an interim
>>> step in the incubation process. e.g. start as a podling, move to pTLP when
>>> certain criteria are met (e.g. >3 active binding votes) and then TLP. I've
>>> not thought this through, just an idea you might consider.
>>> Another commentator observed that "It would probably be good to be clear
>>> on what are the exact characteristics that make this podling pTLP worthy
>>> for the future.  For example, the number of ASF veterans in its ranks." - a
>>> good observation. The danger here is creating an "us" and "them"
>>> environment. Perhaps the podling -> pTLP -> TLP idea resolves this - not
>>> sure.
>>> # What happens if the probationary TLP is not in good graces?
>>> I don't see this as being any different from a TLP. For a TLP the board
>>> says "fix it", if it isn't fixed they clear the decks and invite the
>>> remaining PMC to fix it. If it still isn't fixed it gets axed. What needs
>>> to be defined is who provides these "fix it" ultimatums and when.
>>> Please be *very* careful here. When we set up the IPMC we said the IPMC
>>> would do this - that's the main failure point now. It is mob rule. If a
>>> pTLP reports to board then it's easy, but if reporting to the IPMC it is
>>> harder.
>>> Note, a Director said " the Board will need a *definition* of
>>> probation. This is more than just a wiki page. I believe it needs to
>>> be a page laid down in www.a.o/dev/ that defines the constraints laid
>>> down upon a "pTLP"" I believe answering the above question will provide
>>> this.
>>> # What bits must absolutely be done before probation completes?
>>> Here I don't see any reason for it to be different to podling graduation
>>> (proven ability to be open to new community members, properly vetted
>>> release).
>>> # How do we maintain the "podling" brand?
>>> People are familiar with the concept of a podling. The press understands
>>> the difference between a TLP and a podling. We must not lose this
>>> distinction. The Apache brand is valuable because of our high quality bar.
>>> If we dilute that quality by allowing projects to claim they are official
>>> before they understand what is required of an ASF project we run the risk
>>> of damaging the brand for all projects.
>>> So there you go. I hope I've done a reasonable job of summarizing a 55+
>>> mail thread.
>>> Good luck!
>>> Ross
>>> [1]
>> --
>> Sanjiva Weerawarana, Ph.D.
>> Founder, Chairman & CEO; WSO2, Inc.;
>> email:; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1
>> 650 265 8311
>> blog:
>> Lean . Enterprise . Middleware
> --
> Sanjiva Weerawarana, Ph.D.
> Founder, Chairman & CEO; WSO2, Inc.;
> email:; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1
> 650 265 8311
> blog:
> Lean . Enterprise . Middleware

View raw message