Stephen McConnell wrote:
What I'm getting at is that there is still a lot of work to be done to evolve our specifications to a level that enables the goal of portable components. Additional semantics will be needed in places where they are missing. I figure a lot of these "new" semantics will not relate to the framework - instead that will be defined as a collection of Avalon specifications addressing specific concerns.
Every proposal I have had toward that has been rejected, and talks quickly degenerated. This doesn't foster community building. There has also been a history of somehow having Merlin systems--the technology--somehow drive the specification instead of the community.
Is there more work to do? Of course there is. The question is more how should that work be done.
It also means that a Merlin utility is offered to be promoted as a distributable, and then magically becomes the standard unbeknownst to the rest of the Avalon team.
This sideways definition of semantics and procedural mess is the bad that has come from Merlin. Its as if noone really had a clue what they were agreeing to, and then stuck with what was there. We are not microsoft, and we cannot run the community like their EULAs. Everything needs to be discussed out in the open with all side effects enumerated.
You could try getting more engaged in the process - contributing code, documentation, supporting users, etc. I have to say that there is a big disconnect between the view your presenting in the above paragraphs and the view I (and others) have.
As for improving communication the door is wide open.
I've done more than my share of all of these things. It seems as if I bring up an issue from a user perspective or from a container developer perspective communication shuts down. If I try to find a middle ground, a compromise that might work for both parties, anything I propose gets thrown out. This has repeated itself quite often, so the door to improving communication lies with listening first.
Taking the time to understand a position, the mindset the person is coming from, and how it would fit into the larger picture will help foster communication and rebuild broken bridges. I don't feel that this has happened enough. As long as people summarily dismiss input, no matter how much they disagree with it, then it fosters closed doors and effective communication is shot to h-e-double hockey sticks.
Do consider that *if* I were to take the time to get into a code base I quite frankly don't have a pressing need for at this time, I do not want to deal with being berated, talked down to, and treated like a child.
The bottom line is that there is no process, and there is no effective communication. I really think that only a handful of people on this list really know what the big picture is. Finding that big picture is not an easy task. Not only do they have to sift through words that have no context in technical circles, but they also have to deal with certain people who act unseemly.
This in my opinion is the main reason I can't be involved directly with Avalon. The "spec" or definition of the component contracts is created in such a way that there is a vote on a utility release and then some assume that the utility is the official spec. Not only is this backwards, but I find it has a bad taste.
Defining a spec is important, but proper discussion with proposals, counter-proposals, and resolution must be part of it. Both sides must be willing to compromise. Many times I feel like I have compromised more than my fair share with the other side not budging an inch. This tells me that anything I have to contribute will be rejected. This tells me that I am not welcome.
Now, how can there be a healthy community when people are being excluded? How can there be a healthy community when rational ideas or proposals are presented and then not given proper attention?
--
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."
- Rich Cook
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
