# [RFC] Abolish Short Votes - Thread: https://externals.io/message/104860 - Original archive: https://news-web.php.net/php.internals/104860 - Started by Joe Watkins on 2019-03-21T18:20:32+00:00 - Messages: 7 - RFC: Abolish Short Votes (Accepted) — https://externals.io/rfc/abolish-short-votes.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #104860 — Joe Watkins — 2019-03-21T18:20:32+00:00 URL: https://externals.io/message/104860#104860 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 --- ## #104862 — Christoph M. Becker — 2019-03-21T18:49:17+00:00 URL: https://externals.io/message/104860#104862 > I'd like to raise for discussion another minor, self contained change to > the voting RFC: > > https://wiki.php.net/rfc/abolish-short-votes +1 -- Christoph M. Becker --- ## #104868 — Sebastian Bergmann — 2019-03-22T06:16:45+00:00 URL: https://externals.io/message/104860#104868 Am 21.03.2019 um 19:20 schrieb Joe Watkins: > 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. +1 --- ## #104869 — Niklas Keller — 2019-03-22T07:19:17+00:00 URL: https://externals.io/message/104860#104869 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 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 --- ## #104870 — Joe Watkins — 2019-03-22T07:41:18+00:00 URL: https://externals.io/message/104860#104870 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. Cheers Joe > 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 schrieb am Do., 21. März 2019, 19:20: > > > […] > detail > > […] > is > > […] > detail > > […] > details > > […] --- ## #104876 — Chase Peeler — 2019-03-22T16:01:11+00:00 URL: https://externals.io/message/104860#104876 > 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 > > > > > […] > to > > […] > RFC > > […] > -- -- Chase chasepeeler@gmail.com --- ## #104900 — Joe Watkins — 2019-03-23T18:19:33+00:00 URL: https://externals.io/message/104860#104900 > 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 > > > > > […] > 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. > > > > […] > -- > -- Chase > chasepeeler@gmail.com