Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdi-dev] Decision making process in CDI spec

I recently noticed this: https://github.com/eclipse-ee4j/jaxrs-api/wiki/Committer-Conventions and it seemed quite reasonable to me. I don't mind if we have different rules, but I like how theirs are short, easy to understand and follow, and present on GitHub. We could put them on GitHub wiki as well I think?

LT

On Wed, Apr 7, 2021 at 9:43 AM Matej Novotny <manovotn@xxxxxxxxxx> wrote:
Reviving this thread, I just want to sum it up and decide where to capture the result so that it's visible and not forgotten.

Reading up on this thread, most people agreed on using *simple majority with lazy consensus*.
This means any vote needs more than 50% +1 votes from committers and silence implies approval.

Now, the question is - where do we put this? There are two places I can think of:
* Somewhere in Eclipse website (probably Governance tab)
 - https://projects.eclipse.org/projects/ee4j.cdi/governance
* GH page of project, into README
 - https://github.com/eclipse-ee4j/cdi

@Antoine, @Scott do you have any idea how to edit the eclipse project page?

Regards
Matej

----- Original Message -----
> From: "Antoine Sabot-Durand" <antoine@xxxxxxxxxxxxxxxx>
> To: "cdi developer discussions" <cdi-dev@xxxxxxxxxxx>
> Sent: Tuesday, February 23, 2021 4:24:12 PM
> Subject: Re: [cdi-dev] Decision making process in CDI spec
>
> +1 for simple majority
>
>
>
> Le jeu. 18 févr. 2021 à 00:23, Jason Greene < jason.greene@xxxxxxxxxx > a
> écrit :
>
>
>
> I think for it to truly be a neutral vote, it has to be a deferral to the
> non-neutral voters. So effectively your latter, but a simpler definition is
> essentially the majority of YES/NO votes decides the outcome (non-vote is
> another method of neutrality),
>
>
>
>
> On Feb 17, 2021, at 5:08 PM, Emily Jiang < emijiang6@xxxxxxxxxxxxxx > wrote:
>
> +1 Reza!
> I think we are in agreement to go with a simple majority with no veto power
> from any one of us. Basically we only count +1 and lazy consensus when
> judging whether we have got a simple majority.
>
> One more question: if someone has voted 0 (neither approval nor disapproval),
> should we count towards approval or deduct one from the base when working
> out the simple majority (e.g, we have 8 CDI committers, if 2 committers
> voted 0, we reduce the overall cmmitter base to 6. In this way, 4 votes will
> be a simple majority)?
>
> Emily
>
> On Wed, Feb 17, 2021 at 2:33 PM Reza Rahman < reza_rahman@xxxxxxxxx > wrote:
>
>
>
>
>
> 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
>
> > 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
>
>
>
> _______________________________________________
> 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
>
>
> --
> 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
>

_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev

Back to the top