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.
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?
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.
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?
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.
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.
--
"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]
