| Re: [cdi-dev] Decision making process in CDI spec |
Matej/all, Still depends on what exactly you want to archieve? GH has so many tools these days a few overlap a bit, but there are
And even PRs or issues allow sorting by how many Thumbs Up or Down or Hearts, Rockets or Flowers they got, not sure if those could be adjusted to a real decision making and People understand which of those to use and which may be more nonsense? That’s why Discussions make a cleaner Impression, but I have not seen a single Jakarta spec really use it, guess most of them just have not even learned it exists or tried to activate it, plus that probably isn’t possible unless you are admin. Werner Von: Matej Novotny All, as GH Wiki doesn't support the concept of PRs, I have pushed the changes straight upstream. Apart from including the decision making process, I have also deleted other pages that contained very outdated (CDI 1.1) information, EG group remarks etc. that are no longer relevant. Whole wiki is now a single page information with links, decision making process and contribution note. If interested, check the wiki page here - https://github.com/eclipse-ee4j/cdi/wiki We can OFC adapt it further if needed. Regards Matej ----- Original Message ----- > From: "Matej Novotny" <manovotn@xxxxxxxxxx> > To: "cdi developer discussions" <cdi-dev@xxxxxxxxxxx> > Sent: Wednesday, April 7, 2021 10:14:01 AM > Subject: Re: [cdi-dev] Decision making process in CDI spec > > 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 > _______________________________________________ cdi-dev mailing list cdi-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev |