On Fri, Mar 8, 2024 at 6:30 PM Jim Winstead <j...@trainedmonkey.com> wrote:
> On Fri, Mar 8, 2024, at 12:12 AM, Hans Henrik Bergan wrote: > > On Tue, 5 Mar 2024 at 20:17, Larry Garfield <la...@garfieldtech.com> > wrote: > >> > >> A 3 way up-down vote doesn't make sense. What happens if none of the 3 > options reaches 66%? > >> > >> The viable options here are a single RCV vote (which we've done > before), or a single "Should we do this" vote that requires 66%, followed > by a "when should we do this" vote with 2 options, majority wins. > >> > >> --Larry Garfield > > > > Does this work for you guys? > > This is a lot of votes for a set of pretty simple changes with minimal BC > implications, and maybe there's precedent for it but I don't like voting > about what version to make particular changes in. Adding a language feature > like property hooks is a one-vote RFC but fixing sleep() to take/return > floats and work consistently cross-platform is somehow a six-vote ballot? > Is there anyone who has indicated in any way that they would vote against > making all three changes because one of the three is somehow unacceptable? > What if #3 fails but not #1? > > I agree that there's a clear dependency on #1 (other way round than the above actually... :) ). It might make more sense to do #1 as a primary vote and then the rest as a secondary votes. I think it makes sense to have more votes in this case as each thing has its own consideration and BC impact which is primary difference compare to hooks RFC. > And I'd say leave it up to the release managers to decide what version it > is appropriate for the PR implementing an approved RFC go into. > Micro-managing that by voting does not sit well with me. > > RM has no power to decide about features going in before the first beta. You would need to update the policies to explicitly give RM such power. Voting is currently the only way we have to decide such thing if there is no clear agreement which I think wasn't the case in the PR's proposed for this. Regards Jakub
