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.
Gee, here is a radical idea: instead of wondering what happens to them, just take it for what it was meant. A way to get past stalemates. If we all agree to it, then there is no issue. These types of questions make me believe you intend on making a big deal out of things.
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 rest.
Objections duly noted. However, consider my last attempt to work with you on the Avalon meta project in sandbox. Instead of escalating a stalemate, we are providing an out. Community rules--whether in your favor or mine or someone else's it doesn't matter.
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!
Again. Your issues are duly noted. As to point two, I believe that is the main reason why we are stalemated and not moving forward. We don't seem to have shared objectives.
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.
Thank you for putting words in my mouth, and implying motivations I don't have.
Instead – think about shared objectives.
Please list these, because every time I think I know what they are, you come along and blow away my view of what the shared objectives are.
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?
Tried that, got yelled at. Not interested in getting yelled at anymore.
So. Promise not to yell, and I will help you out. Otherwise we need to look at other activities.
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.
I think I've said enough on the subject--everything I say keeps getting twisted somewhere between where I put the suggestions down and you respond. I'm tired of that, so I'm not rehashing it anymore.
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.
Not exactly. What we have in Avalon is a fairly disjointed picture so far. There are some common points, and we should be very happy about that. What we don't have is a model where a component developer can freely go between all Avalon containers and expect everything to work properly. That has been my cheif short-term goal. However, every time I attempt that goal I meet opposition. SOmething is wrong. What is wrong is not technical in nature, but management related. Tell me, what do I have to do... and "live and let live" isn't the answer.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
