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
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