hi, On Tue, Mar 17, 2015 at 5:01 AM, Philip Sturgeon <pjsturg...@gmail.com> wrote: > While you can easily question the value or motives of Anthony's post > about voting irregularities, some simple improvements can be made > which are uncontroversial. I consider this a low hanging fruit, like > restricting the sale of firearms to people who are clearly drunk. > > I mentioned on that other thread that the FIG has a rule saying you > cannot cast a vote in any vote that was initiated before your > membership was activated. That annoyed me a little as I missed out on > my vote for PSR-1 and PSR-2, but it's a great way to keep some > potential foul play out of things. > > This may not have ever happened. > > This will not fix every imagined issue with voting. > > If it was happening, it would be bad, right? > > Let's just shove that rule in the wiki and call it done.
To be honest I do not think there are much issues related to this specific case. However i worry much more about: - minimal discussion time before voting - actual announces on internals, for discussions phase, voting phase and approval - avoid changes in a RFC during and after the voting phases but typos these are the technical measures I want to implement in the wiki to avoid such things to ever happen again. The tricky parts being the edition of a RFC during and after voting. While typos could be fine, I tend to think that it should not be allowed. One possible way is to have the wiki post on internals any changes happening in a RFC during or after the votes, so a peer review can happen. The time periods limitations are easy to deal with and will ensure a clear rule for everyone. The announces should be automatic, sent by the wiki, in a way that one cannot move from one phase to another and forget to send the announces mails. On the same note, I would like to get some tech writers involved in the RFC process. We have seen some very low quality RFC (the RFC itself not necessary the idea behind it). Having tech writers, native-like speakers, involved would make the wording and correctness of a RFC much less open to interpretations and clear. A side effect, it will also the lazy among us to actually use the RFC in a better way without being stopped due to some writing issues :) Thoughts? Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php