|
Hi Jim,
That sounds reasonable to me. If we do that, I think we should have some way to say "We've voted on this X times, this is the final vote". I'm not sure what that is, but what you're saying does sound reasonable.
Another option might if there is a -1 within the 2 weeks, we simply just add another week or two for others to change their vote.
James R. Perkins
Software Developer
IBM
From: Jim Krueger <jckofbyron@xxxxxxxxx>
Sent: Wednesday, June 24, 2026 08:35
To: Jakarta Rest project developer discussions <rest-dev@xxxxxxxxxxx>
Cc: James Perkins <jperkins@xxxxxxx>
Subject: [EXTERNAL] Re: [rest-dev] Request to Change Committer Conventions
Hi James, I like and agree to the spirit of this and I entirely agree with your “lazy consensus” suggestion. However, I’d like to make one suggested addition. Historically a -1 vote comes along with an explanation of that vote. Therefore, I
Hi
James,
I like and agree to the spirit of this and I entirely agree with your “lazy consensus” suggestion. However, I’d like to make one suggested addition. Historically a -1 vote comes along with an explanation of that vote. Therefore, I think that a -1
vote should equate to a reset of all votes, essentially starting the voting over again. In that way everyone who voted +1 previously would consider the reasoning behind the -1 vote and vote again. If the +1 votes still outnumber the -1 votes after that,
then the approvals win as you said.
On Jun 24, 2026, at 10:23 AM, James Perkins via rest-dev <rest-dev@xxxxxxxxxxx> wrote:
Hello All,
I'd like to make some changes to the committer conventions. This specification seems to have significantly slowed down and stopping the specification from being able to move forward.
I'd like to add a lazy consensus after the two week period. If a pull request does not have the 3 required votes, it requires 1 approval after the two weeks to be merged. This will unblock the PR queue we have now.
I'd also like to remove the -1 kills everything approach. I think we should use a majority. If there are 3 approvals and one -1, the approvals win. If there are more -1's than approvals, then the -1's win 🙂 In the event of a tie and no one is willing to change
their vote, the specification leads will make the decision.
Please note we really need to unblock the pull request queue. Not only is this holding up this specification, it's also holding up the Jakarta EE specifications as well.
James R. Perkins
Software Developer
IBM
_______________________________________________
rest-dev
mailing list
rest-dev@xxxxxxxxxxx
To
unsubscribe from this list, visit https://accounts.eclipse.org
|
