Hi,
as discussed during our last meeting, here is some basic thoughts about
how the Grizzly community should work. I'm in a favor of a more Apache
approach than a GlassFish approach for dealing with the community (I'm
not blaming GlassFish way of working, but since we have the choice, I
would like something more open). Mainly, I propose for our community:
+ Vote on every release, like the Apache folks are doing. This is
different from GlassFish where no votes occurs.
+ Release frequently, and mark the release as alpha or beta or stable. I
propose we start with 1.5.0.
+ Branch release and never block the trunk.
When voting, I would also like to allow non binding vote to count. Why?
Because peoples that use Grizzly outside Sun might face different
problem than inside. This is something I don't like in GlassFish because
external users aren't enough involved when it is time to decide the
stability of a build (they cannot vote).
....I really want this community open :-)
Below is some cut&paste concept from Apache I would like us to follow.
> Communication is done via mailing lists. These identify "virtual meeting rooms" where conversations happen asynchronously, which is a general requirement for groups that are so geographically distributed to cover all time zones (like it's normally the case for the various Apache communities).
>
> Some projects additionally use more synchronous messaging (for example, IRC or instant messaging). Voice communication is extremely rare, normally because of costs and the language barrier (speech is harder to understand than written text).
>
> In general, asynchronous communication is much more important because it allows archives to be created and it's more tolerant on the volunteer nature of the various communities.
I would avoid having a forum, but an IRC might be good.
> Decision Making
>
> Projects are normally auto governing and driven by the people who volunteer for the job. This is sometimes referred to as "do-ocracy" -- power of those who do. This functions well for most cases.
>
> When coordination is required, decisions are taken with a lazy consensus approach: a few positive votes with no negative vote is enough to get going.
>
> Voting is done with numbers:
>
> * +1 -- a positive vote
> * 0 -- abstain, have no opinion
> * -1 -- a negative vote
>
> The rules require that a negative vote includes an alternative proposal or a detailed explanation of the reasons for the negative vote.
>
> The community then tries to gather consensus on an alternative proposal that resolves the issue. In the great majority of cases, the concerns leading to the negative vote can be addressed.
>
> This process is called "consensus gathering" and we consider it a very important indication of a healthy community.
OK let start discussing :-) I will then use the outcome for docs on our
site.
Thanks
-- jeanfrancois