[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdi-dev] Decision making process in CDI spec
|
> 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