| Re: [jakartaee-platform-dev] Nature of Ongoing Votes |
|
Steve Millidge wrote: SM> Given it is summer and I have been away. I am a little confused by SM> the ongoing votes – are these project committer votes or are they SM> specification votes i.e. spec committee votes? I am assuming this SM> is a committer vote as this is on the project mailing list not on SM> the spec committee mailing list. SM> I have seen various comments like (binding) and <company> votes so SM> not sure what these signify. SM> I would like clarification as a -1 on a committer vote usually SM> signifies veto. On what criteria does the vote pass? -1 means "no, I don't want this". See Scott Marlow's response. SM> Apologies if I have missed this when I have been away. I have been SM> through the archive but couldn’t see anything obvious defining the SM> rules of the ballot. Scott Marlow wrote: ScottM> I think the ScottM>
https://www.eclipse.org/lists/jakartaee-platform-dev/msg04054.html ScottM> thread discussed this and clarified that Platform project ScottM> committers are expected to vote with one of "responses: +1 ScottM> (yes), -1 (no, or veto), and 0 (abstain)" but all mailing list ScottM> members are also welcome to vote even though only comitters ScottM> votes will be counted. Yes, thanks for digging that up and sharing it, Scott Marlow. Ivar Grimstad wrote: IG> We had a similar discussion around Jakarta EE 9. Here are the IG> minutes from that discussion: IG>
https://jakartaee.github.io/jakartaee-platform/minutes/2019/2019-11-26.html IG> In the context of adding specifications, we then decided on the following: IG> "DECISON: Decisions will be made with majority votes. Unanimous is not needed." Here is my judgement of the applicable precedent for creating the Platform Project Release Plan. - Every list member is eligible to vote. - Only the committers on the platform project listed at
https://projects.eclipse.org/projects/ee4j.jakartaee-platform/who have their votes counted. - >From the set of committers that have voted - We count the +1s, 0s, and -1s. - The option with the highest number of votes wins. I am unclear on what we do in the event of a tie. I suggest we add in the non-binding votes in the case of a tie. This is a suggestion, not a requirement. If we add in the non-binding votes and we still have a tie, I'm not sure what to do. Steve Millidge wrote: SM> OK as it is a specification project shouldn't these sort of SM> decisions be in the release plan and therefore subject to the EFSP SM> and EFSP voting rules. Ed Burns wrote: https://www.eclipse.org/lists/jakartaee-platform-dev/msg04054.html EB> The fact remains: even if the voting results in a non-zero number EB> of new specs suggested for inclusion in EE 11, when the Platform EB> Project submits the Plan including those new specs, the parties EB> that vote on approving the Plan have the final say. I agree with Steve that the Platform Project Release Plan should represent the consensus view of the Platform Project, as determined by the BALLOT process. Therefore, I requset we revise the plan when the BALLOT process is complete and then present it to the Specification Committee. Then, as Steve Millidge observes, the EFSP voting rules apply to approve or deny the Release Plan. |
edburns@xxxxxxxxxxxxx | office: +1 954 727 1095 | Calendar Booking:
https://aka.ms/meetedburns | | Please don't feel obliged to read or reply to this e-mail outside | of your normal working hours. | | Reply anonymously to this email:
https://purl.oclc.org/NET/edburns/contact |