[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdi-dev] Decision making process in CDI spec
|
I am not sure what you're getting at but I was merely saying I changed the wiki straight away instead of sending a PR proposal (because that's not possible for GH wikis).
The process I described there (as I am sure you read) relates to mailing list as a place where the vote would take place.
Regards
Matej
----- Original Message -----
> From: "Werner Keil" <werner.keil@xxxxxxx>
> To: "cdi developer discussions" <cdi-dev@xxxxxxxxxxx>
> Sent: Friday, April 9, 2021 2:54:15 PM
> Subject: 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
>
> * Issues
> * PRs
> * Projects (a Kind of Kanban board allowing to Combine also multiple
> repositories within an organization or just a single repo)
> * Wiki (why would that have a PR, you can Always link to something, but
> it might be more intuitive in the issue tracker)
> * Discussions (relatively new, it is much more towards actual
> decision-making than all the others, you can up- or down-vote ideas or
> questions and set them to answered, not sure if links to PRs work,
> probably not much more than Wiki but it could be Closer to Issues)
>
>
>
>
> 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
> Gesendet: Freitag, 9. April 2021 14:22
> An: cdi developer discussions
> Betreff: Re: [cdi-dev] Decision making process in CDI spec
>
>
>
>
> 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
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cdi-dev
>
