An interesting read. So is Nicola's cut/paste job from Ken Coar. So is Steffano's on Tomcat/Catalina.
OK, We have one primary art - Avalon-Framework interfaces. Despite chatter about Avalon5 they are remarkably stable. The vision of a container is something we all have in our heads clearly. It is easy for us to imagine a new container. New containers are often revolutions, and lo and behold we often start coding them in earnest. We have a excellent newer container called Merlin that was formed from one such revolution. We have an excellent older container called Phoenix that itself was previously formed from one such revolution. Just because we have two containers and a number of smaller beany projects that suport them, it does not mean that we are dysfunctional. It is the nature of this ambitious project to deliver large revolutionary as opposed to slowly evolved projects (when considering cntainers).
- Paul
Various quotes (deliberately without attribution):
I think it makes sense to do the first prototyping in avalon-sandbox,
and everytime we have consensus on a piece, that can go someplace new,
whether it's a new repository or a branch in the existing one.
The container needs to be started in avalon-sandbox.
It is pretty cool to have a plethora of codebases and snippets
I do like [the] idea of having multiple proposal directories. Yes,Does no one realize that the Avalon project has institutionalized a
there will be one final solution chosen, but I don't think that
should preclude having multiple trees and approaches to view and
hack on during that decision making process. That way radical
ideas can have a place to be demonstrated to the community before
the community adopting them.
psychology that says fork first, consensus later? Avalon appears to be so
dysfunctional as a community that people first try to create a proof that an
approach is the correct one because otherwise the community can't agree.
The presumption is that there will be multiple ideas and that consensus
can't be achieved without competition. At first the code is "just a
proposal", but when consensus is not forthcoming, the project (hard to call
it a community at that point) just ends up with disparate pieces.
Partially, what appears to be happening, even now, is that people (perhaps
subconsciously) are jockeying to preserve their ability to do what they want
without having to reach a consensus. They'll only reach one when/if they've
finished competing.
But I don't believe that this is about ego and competing. A related, and
very significant, issue appears to be a concern about being shut out of the
process, and having one faction eliminate another. There is a major lack of
trust within this community. And that is a very unhealthy psychology.
Furthermore, because the community does not agree beforehand on what
approach to take, it cannot effectively marshal community resources.
Instead of having people working on different facets of a common vision, it
wastes its resources developing competing visions of the same facet. And it
alienates potential contributors (and consumers).
Constantly developing multiple implementations, and then voting on which one
is best is not how a community project is supposed to work. At least not by
my definition of community, nor by the one that I believe the ASF is trying
to foster. Someone please correct me if I am wrong.
So ... having just let loose with this criticism, where are the constructive
suggestions that I ought to offer to address it? Well, let's all
acknowledge that on the positive side, despite the current community issues,
Avalon has delivered important, useful, technology, and we all want it to
continue to do so. [Wouldn't be here otherwise!] I recognize that the
current psychology didn't appear overnight, and is unlikely to change via an
epiphany. Even the most reasonable people here are showing the symptoms.
But people really ought to reflect on what is going on here, and why they
feel the way that they do. And THEN, what they can do to change it in favor
of community building.
So what to do? The Avalon Community is part of a larger Community. I
submit that in the face of these internal issues, the solution is to trust
the ASF Community Process -- as it is promoted. No more jockeying for
position or protecting turf. Accept the philosophy that the community is
more important than the code. I understand that you cannot move forward in
an climate of mistrust, either social or technical. So if you can't trust
your fellow community members, trust the larger community and the process --
consider them a safety net. Hopefully the former can be rebuilt from the
latter.
I'll conclude with a thought regarding technical vetoes. Consider this: why
must a justification must be given for a technical veto? Do you suppose
that the purpose is simply to provide an excuse for the veto? I submit that
it is about providing a basis for reaching a new consensus. Consensus isn't
about one person being able to act as a roadblock. It is about focusing
attention on critical issues on the belief that the community consensus will
be the best solution available at that time.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
