Re: [cdi-dev] Decision making process in CDI spec

[Gurkan Erdogdu <gerdogdu@xxxxxxxxxxxxx>]

> On 17 Feb 2021, at 12:36, Matej Novotny <manovotn@xxxxxxxxxx> wrote:
> 
> Giving anyone veto rights sounds very dangerous to me. Ideally, you want to reach full consensus whenever possible but you cannot allow potential blocking by any one person indefinitely.

 A veto without a justification must be invalid and has no weight.

- Gurkan

> On 17 Feb 2021, at 12:36, Matej Novotny <manovotn@xxxxxxxxxx> wrote:
> 
> Giving anyone veto rights sounds very dangerous to me. Ideally, you want to reach full consensus whenever possible but you cannot allow potential blocking by any one person indefinitely.
> 
> Personally, I am +1 for simple majority with lazy consensus (for that we have a way to handle commiters who don't partake in vote).
> 
> Regards
> Matej
> 
> ----- Original Message -----
>> From: "Gurkan Erdogdu" <gerdogdu@xxxxxxxxxxxxx>
>> To: "cdi developer discussions" <cdi-dev@xxxxxxxxxxx>
>> Sent: Wednesday, February 17, 2021 9:07:43 AM
>> Subject: Re: [cdi-dev] Decision making process in CDI spec
>> 
>> 
>> 
>> 
>> And that is never a good practice in an open-source project. Just my
>> thoughts…
>> It is used in ASF, https://www.apache.org/foundation/voting.html
>> 
>> It is just an option :)
>> 
>> Regards.
>> Gurkan
>> 
>> 
>> 
>> 
>> On 17 Feb 2021, at 11:00, Ivar Grimstad <
>> ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx > wrote:
>> 
>> I think I would avoid that since it effectively gives a committer veto
>> rights. And that is never a good practice in an open-source project. Just my
>> thoughts...
>> 
>> Ivar
>> 
>> On Wed, Feb 17, 2021 at 8:44 AM Gurkan Erdogdu < gerdogdu@xxxxxxxxxxxxx >
>> wrote:
>> 
>> 
>> 
>> Hi
>> 
>> Option C: No -1 blocker vote
>> 
>> It can be simple as no -1 blocker vote from any committer. If there are some
>> -1’s, we need to clear it before accepting….
>> Regards.
>> Gurkan
>> 
>> 
>> 
>> 
>> On 17 Feb 2021, at 03:06, Scott Stark < starksm64@xxxxxxxxx > wrote:
>> 
>> 
>> As of tomorrow there will be 8 committers, so 5 would be a simple majority
>> while 6 would be a super majority. In either option, lazy consensus should
>> also be used so that silence implies approval. You have to voice opposition
>> to be counted on the nay side of a vote.
>> 
>> Until it proven to be necessary or desired, I would prefer starting with a
>> simple majority decision process.
>> 
>> 
>> 
>> On Tue, Feb 16, 2021 at 4:56 PM Emily Jiang < emijiang6@xxxxxxxxxxxxxx >
>> wrote:
>> 
>> 
>> 
>> In today's CDI meeting, we discussed how to make decisions when there are
>> split views. As you know, after some lengthy discussion, we need to make
>> decisions for some technical issues.
>> 
>> I took a todo and brought this up today's Jakarta EE spec committee meeting
>> today for some guidance. In the meeting, I was told that each spec has the
>> freedom to choose the decision making process. Eclipse Foundation might come
>> up with a recommendation but the adoption is optional. With this in mind, we
>> can make our own decision making process. After we have agreed on the
>> decision making process, we need to document it clearly.
>> 
>> A couple of suggestions:
>> 
>> Option A: simple majority of committers' votes.
>> 
>> e.g. if we have 9 committers and solution A is put up for a vote,
>> solution A will be accepted if 5 or more committers vote +1.
>> 
>> Non-committers are encouraged to vote but they are counted as non-binding
>> votes.
>> 
>> 
>> Option B: super majority (2/3) of committers' votes.
>> 
>> e.g. if we have 9 committers and solution A is put up for a vote,
>> solution A will be accepted if 6 or more committers vote +1.
>> 
>> Non-committers are encouraged to vote but they are counted as non-binding
>> votes.
>> 
>> Feel free to add more options.
>> 
>> Thoughts?
>> 
>> 
>> --
>> Thanks
>> Emily
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cdi-dev
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cdi-dev
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cdi-dev
>> 
>> 
>> --
>> Ivar Grimstad
>> Jakarta EE Developer Advocate | Eclipse Foundation
>> Eclipse Foundation - Community. Code. Collaboration.
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cdi-dev
>> 
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cdi-dev
>> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev