On Fri, Mar 8, 2024, at 8: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? > > ===== Proposed Voting Choices ===== > > ### 1. Enhancement of Precision: Float Arguments for Sub-Second Precision > > **Should we extend `sleep()` to accept floats for sub-second delays?** > - Yes > - No > > **Which PHP version should implement this feature if accepted?** > - 8.4 > - 9.0 > > ### 2. Normalized Return Values on Windows > > **Should we modify `sleep()` on Windows for consistent return values?** > - Yes > - No > > **Which PHP version should implement this feature if accepted?** > - 8.4 > - 9.0 > > ### 3. Enhanced Return Value Precision > > **Should we increase `sleep()` return value precision to include > fractions of a second?** > - Yes > - No > > **Which PHP version should implement this feature if accepted?** > - 8.4 > - 9.0 > > @Tim >>adding a short *nix explanation of when sleep will > return earlier than expected would be helpful > > Where should that be? in the "Introduction" section? or the "Proposal" > section? (or elsewhere?)
That seems reasonable, yes, assuming you want the change broken up into 3 votes. I haven't actually looked at the RFC itself in detail to say if that's wise or not. Do things still work if any given subset passes but not others? Generally you would put the above into the Voting section, with a text note saying that the main votes are 2/3 and the "When" votes are 50/50. Then structure the RFC so that it breaks into 3 pieces naturally, and note in the introduction that there's 3 related changes under consideration. --Larry Garfield
