incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: [RANT] Mission of the incubator
Date Sat, 28 Jan 2006 06:27:35 GMT
On Friday 27 January 2006 23:58, Sam Ruby wrote:
> I am on the board of directors, and have been so for nearly four years
> now.  I was present at the time the Incubator was established, and voted
> for it.  I do believe that I am qualified to speak to what the original
> and true motivation of the incubator was then and is now.  Furthermore,
> we have seen such people as Roy Fielding reconfirm key aspects of the
> intent of the incubator.

No need to wave the authorative stick around ;o)

> As I said, my perspective is different than yours.  What I see is people
> who try to "move the goalposts" and establish ad-hoc rules to exclude
> people and proposals they don't intend to participate in.  Most such
> efforts are self-defeating, so I don't get too worked up about it.

AFAIK, the Incubator is more or less incubating itself, and need to adjust to realities as
they occur. Calling that "move the goalposts" is a bit harsh, IMHO.

> One such attempt on the Kabuki proposal, however, in particular bothers
> greatly. You see, I don't care too much about the current state of code,
> I do strongly believe that a good community will correct all such
> wrongs.  (Note: I would like to see Kabuki deliver on its server
> agnostic potential, and may end up exploring contribution of Python
> and/or Ruby code to help seed this).

Agree.

> What I DO care more about is communities and the people that make them
> up.  

THIS seems somewhat contradictory. You care of the communities, but in the Kabuki proposal
(as Raphaël correctly points out) there is no such established existing community.

SO, let's not diminish the credits of the codebase and the individuals in the Kabuki proposal.
I am sure they are outstanding people in their own right.

> As I have come to believe that tasks assigned to many are 
> effectively assigned to nobody, I would prefer that there be either a
> single or primary mentor for Kabuki.  And frankly, I believe that Andy
> is the best person for that job.

Agree.

> One attempt to "move the goalposts" was to disqualify Andy as he was "in
> the pay of the project sponsor".  The clear implication being that Andy
> isn't one of "us", he is one of "them" and can't be trusted.

This is not how _I_ interpreted Raphaël's concerns. I take it as "call for more active support
from ASF peeps in general.

> I defy anybody to attempt to apply that particular standard to Roy
> Fielding and JackRabbit.

I think Raphaël have clarified the distinction, and again not about the individuals themselves,
but the lack of "others".

> Andy is truly one of "us".  And the best way that I know of to create
> more like him, execute on the advocacy vision of Brian, and the mission
> of the incubator as established by the ASF board, is to help Andy create
> a vibrant, diverse, and sustainable community around Kabuki.

Concluding; The discussion in the Incubator should not revolve around this group, but around
the policy of what the pre-requisites are for entry in respect of "established community"
and what such phrase encompass. Scenarios like;
 1. "Hi. I have on my spare time been ..."
 2. "Hi, me and my best friend have as a final exam project been..."
 3. "Hi, our company have 12 people ..."
 4. "Hi, we are a group of 3 loosely coupled guys across the world who are..."
 5. "Hi, we a department of 300 developers at IBM who all are..."

"... working on this great project XYZ that is suitable to incubate at ASF, because.."

I think that all of the above are by some people considered 'border line' cases, irrespectively
if they are brought to ASF by committers, members or Board members, and the Incubator should
not only establish the pre-requisites but possibly a chart of "path to incubation", which
can help projects like the above to learn what they need to do prior to coming to ASF.


Cheers
Niclas
Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message