| Re: [cdi-dev] Decision making process in CDI spec |
_______________________________________________I think a simple majority with no veto right is the best way to make progress at this juncture. We really need to get Jakarta EE innovating once again, even if decisions aren't perfect or make everyone happy at a given point in time.
On 2/17/21 8:27 AM, Werner Keil wrote:
I don’t think that’s how those Projects at Eclipse (Jakarta EE) now work anyway.
In theory there could be non-binding votes by people on the Mailing list but only the 7 committers listed here https://projects.eclipse.org/projects/ee4j.cdi/who
(plus potentially another one or two who may be voted on right now) have binding votes.
This is also similar in other places like the Spec Committee, where we occasionally record one or the other subscriber to the mailing list but those are not binding votes for a spec release or update vote.
Regards,
Werner
Von: Matej Novotny
Gesendet: Mittwoch, 17. Februar 2021 10:36
An: cdi developer discussions
Betreff: Re: [cdi-dev] Decision making process in CDI spec
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
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cdi-dev
> _______________________________________________
> cdi-dev mailing list
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cdi-dev
>
> _______________________________________________
> cdi-dev mailing list
> 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
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cdi-dev
>
>
> _______________________________________________
> cdi-dev mailing list
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cdi-dev
>
_______________________________________________
cdi-dev mailing list
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