Re: [rest-dev] Request to Change Committer Conventions

[Jim Krueger <jckofbyron@xxxxxxxxx>]

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