> A compromise between the two positions could be to allow voting to be extended ONCE, and only within the first X% of the voting period. So, if someone calls for a 14 day voting period, within the first 7 days they can extend it at most one time, and it can never be extended after the first 7 days.
It's tempting to try and encode "requirements" into rules, but we're not looking to make complicated rules and the only requirement we have is that votes should last at least two weeks for everything. The simpler the rules are, the better for everyone. > Also, if you are going to be updating the language anyway, why not specify that an exact date and time be given for when voting will end. I think most people already do this - but this would codify it and prevent the possibility of ambiguity in the future. We have to deal with real life, and the fact is that hardly anyone can schedule their lives around their contributions to PHP: Days seem to be an exact enough measure, and as you say, some people do give a time when the vote will close anyway. However, declaring they must isn't very realistic - if they miss closing the vote by 15 minutes, does it invalidate the vote ? Are we going to invent a set of criteria that would invalidate the vote ? This seems like a rabbit hole we need not get stuck in. Cheers Joe On Fri, 22 Mar 2019 at 17:01, Chase Peeler <chasepee...@gmail.com> wrote: > > On Fri, Mar 22, 2019 at 3:41 AM Joe Watkins <krak...@gmail.com> wrote: > >> Morning Niklas, >> >> Allowing the extension of voting leaves us open to someone extending the >> voting period simply because they don't feel like they have the result >> they >> wanted. >> >> The problem we're trying to solve is votes that are too short, while >> providing the flexibility to have longer votes, but we need to know at the >> start of voting what the voting period is going to be. Take for example >> the >> case where a third party to an RFC is planning some work based on the >> results of the voting, it doesn't seem fair that their schedule could be >> interfered with by the first party after voting starts. >> >> In the vast majority of cases where someone forgets or isn't aware of a >> holiday period, they are going to be told on day one of voting (if not >> before, during discussion), and can simply adjust the voting period, and >> restart the vote (if there has been any votes at the first interjection) >> without having lost any time. >> >> First, I don't even have a vote. Second, I'd be ambivalent about the > ability to extend voting even if I did. A compromise between the two > positions could be to allow voting to be extended ONCE, and only within the > first X% of the voting period. So, if someone calls for a 14 day voting > period, within the first 7 days they can extend it at most one time, and it > can never be extended after the first 7 days. > > Also, if you are going to be updating the language anyway, why not specify > that an exact date and time be given for when voting will end. I think most > people already do this - but this would codify it and prevent the > possibility of ambiguity in the future. > > >> Cheers >> Joe >> >> On Fri, 22 Mar 2019 at 08:19, Niklas Keller <m...@kelunik.com> wrote: >> >> > Resend, because sent from the wrong address previously. >> > >> > +1, but it should probably be possible to extend the voting period once >> > started, but not shorten it. This allows for extension during holidays >> in >> > case the author didn't think about that when starting the vote. >> > >> > Regards, Niklas >> > >> > Joe Watkins <krak...@php.net> schrieb am Do., 21. März 2019, 19:20: >> > >> > > Evening internals, >> > > >> > > I'd like to raise for discussion another minor, self contained change >> to >> > > the voting RFC: >> > > >> > > https://wiki.php.net/rfc/abolish-short-votes >> > > >> > > This seems like another no-brainer to improve and clarify the voting >> > > process. As with abolishing narrow margins, I'm focused on this one >> > detail >> > > and wider discussion of how we may improve other parts of the voting >> RFC >> > is >> > > not appropriate in this thread: We either have a consensus that this >> > detail >> > > should be changed or we don't, we do not need to discuss any other >> > details >> > > here. >> > > >> > > Cheers >> > > Joe >> > > >> > >> > -- > -- Chase > chasepee...@gmail.com >
