+1 but have you considered GitHub Discussions instead, see https://github.com/unitsofmeasurement/indriya/discussions which we created in the RI of JSR 385 for decision making? ;-) Werner +1 on putting this on CDI github wiki! I like this idea as I am also leaning towards having it primarily on GH. While at it, we should probably clean up the Wiki; it is massively outdated :-D
I'll take a look at it.
----- Original Message ----- > From: "Ladislav Thon" <lthon@xxxxxxxxxx> > To: "cdi developer discussions" <cdi-dev@xxxxxxxxxxx> > Sent: Wednesday, April 7, 2021 9:50:00 AM > Subject: 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 > > _______________________________________________ > 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 |