+1
This type information should go in some document or FAQ (probably
without the GlassFish bits) on the Grizzly project page.
I think the first thing to decide is; what's the name of the document
or category we'd put on this type of information?
Then, we can decide the appropriate place for it to go.
charlie ...
Jeanfrancois Arcand wrote:
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
--
Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)
<http://java.sun.com/docs/performance/>