On Fri, Mar 20, 2015 at 7:30 PM, Pierre Joye <pierre....@gmail.com> wrote:
> 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 > > I'd be happy to lend a hand with that. --Kris
