avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [RRT] Getting back to the basics (long)
Date Wed, 30 Jul 2003 18:48:08 GMT

Berin Loritsch wrote:

> Stephen McConnell wrote:
>> Berin Loritsch wrote:
>>> As this affects the whole of Avalon, I would like to know your 
>>> thoughts,
>>> comments, concerns on this subject. If we would like to adopt it as 
>>> our future
>>> direction, let's do it. If there are any concerns, let's lay them on 
>>> the table. 
>> We have a charter that states what Avalon is about - "service and 
>> component management".
>> Within that scope there an infinite number of possibilities. However, 
>> when we consider community dynamics, the interests of different 
>> users, and personal objectives, we see a tendency of people to move 
>> towards concepts that interest them. And from time-to-time we move 
>> from one center-of-gravity to another. In effect, this represent the 
>> migration of interests drawn by the emergence of new ideas, solutions 
>> or opportunities.
>> Here are my thoughts about the big picture from this perspective:
>> Stop the process of *forced* convergence.
>> -----------------------------------------
>> * Nobody here wants to be forced to do anything.
>> * Its driving people away.
>> * Its not focussing on needs.
> I'm sorry, I wasn't aware that the RRT was forcing convergence. Just
> trying to generate healthy conversation. 

Included in your RRT was the subject of a "Community Agreement Process". 
In that description you suggested that Jakarta rules are insufficient (a 
point I would contest). Within those guideline you proposed something 
that in my view attempts to engineer the direction of the community.

Berin Loritsch wrote (original post):

> * Once all _questions_ have been answered about the differing 
> proposals, and
> the proposals are finished with any modifications due to the questions,
> we place it up for vote. The proposal that wins, wins. No exceptions.

This set up rules - it changes the scope of what people here can do. I 
states that the community must follow without exception. That is a 
equivalent to modification of the charter. What happens if someone does 
something inside the scope of existing Avalon charter but outside the 
scope of the "plan". Are they expelled from Avalon? Are they coerced 
into doing things they don't want to do? Or will they simply be pushed 
out by a select few. These are fundamental issues that impact the 
community and our freedom to work within the charter that has been 
established by the Apache Board.

The alternative is to respect the community as a process from which 
things emerge - promote and support the best of those and learn from the 

>> Instead - let thing evolve because this community wants them to 
>> evolve. As you know, I'm quite keen on seeing the development here in 
>> Avalon of a common containment API but I'm also opposed to the notion 
>> of one container. In fact the vision I like is the ability to pull in 
>> a container matching your own needs - dynamically. Its a vision with 
>> lots of commonality with your own thoughts. But if we put down a rule 
>> that said there must one and only one container - we would 
>> immediately in conflict. The problem here is that rules force us into 
>> directions which we may not want to go. Underlying this is the 
>> problem that rules can used to coerce members of the community in 
>> unforeseen ways.
> Any issues with the vision in general other than the one container issue? 

* I'm not interested in a start from scratch scenario
* Instead build on what we have based on shared objectives
* Opposed to the Community Agreement Process in general

There may be other issues - but these these leap out at me!

>> Another approach is to encourage and foster the contributions of 
>> developers here at Avalon based on shared objectives - and through 
>> this, facilitate the evolution of best-of-breed solutions. To enable 
>> adventure, good times, and great results.
>> There are some things we can do to facilitate this:
>> * get rid of the notion of managing the community (less stress)
>> * introduce a vibrant release process (frequent releases)
>> * encourage experiments (more surprises)
>> * capture and promote the best of breed (recognition)
> I could have swarn that I had 3 out of 4 of those nailed. As to
> managing the community, I believe this is largely a misconception. 

If you want to propose a project for sandbox - then cool - from there 
you can work towards what you have in mind. It does not really fit 
within my own view of where we are heading so I guess I want be an 
interested observer. But if you introduce the notion of rules - your 
kind of twisting my arm to work within the context of something I 
haven’t bought into. Remember - you said - "No Exception". That's 
attempting to engineer community direction and that's simply not what we 
should be attempting to doing.

Instead – think about shared objectives.

> I want to focus on something here. I want to move toward something
> good. I have a ton of ideas, but if I am the only one with them then
> what's the use? 

Not a lot.

Why not try working with some of the other actives going on and see what 
you could contribute?

> Also, it is clear that status quo of little islands operating to 
> themselves
> is not working. That requires some management. I am looking for a way 
> that
> lets us to kick-A stuff with the minimal amount of friction/management
> necessary. It is important to realize that you as a PMC member are 
> equally
> charged with managing this community as I am.

Yep - and in my capacity as PMC member I have already put forward some 
recommendations. Notable amongst those recommendations was the issue of 
community engineering and the negative impact this has on members of the 
community. I also addressed priorities facilitating community growth and 
development. Underscoring that proposal is my firm belief that this 
community does not need the type of management your describing.

> As to the community guidelines I put forth in the RRT, I thought that 
> they
> encouraged best of breed recognition. The idea for the container outline
> encouraged experiments--some of them could be quite wild. And all of this
> would require a vibrant release process.

So in effect what exists here in Avalon today is what you are aiming 
for. We have experiments - some of which are wilder than others. But I 
must confess - our release process is rather stale. But I'll be getting 
on to that ASAP.

Cheers, Steve.


Stephen J. McConnell

Sent via James running under Merlin as an NT service.

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message