Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85353
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU4CTEZSPG7By5t-N5eLY+D==Vk5AuZg5v3GzkgLwWGACg@mail.gmail.com>
References: <CABDNdAFS=rDpBgPJPYKZ+7mWCUtyam=y3ude9QEdnmis08U-7w@mail.gmail.com>
	<CAEZPtU4CTEZSPG7By5t-N5eLY+D==Vk5AuZg5v3GzkgLwWGACg@mail.gmail.com>
Date: Fri, 20 Mar 2015 19:33:23 -0700
Message-ID: <CAKOpQSyEXCmDxdbRA_n5iRypeT=u37PVGvznijEU+i8y3dgsVw@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Philip Sturgeon <pjsturgeon@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01182c8ec846320511c34196
Subject: Re: [PHP-DEV] Only Vote on Votes Initiated After Registration
From: kris.craig@gmail.com (Kris Craig)

--089e01182c8ec846320511c34196
Content-Type: text/plain; charset=UTF-8

On Fri, Mar 20, 2015 at 7:30 PM, Pierre Joye <pierre.php@gmail.com> wrote:

> hi,
>
> On Tue, Mar 17, 2015 at 5:01 AM, Philip Sturgeon <pjsturgeon@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

--089e01182c8ec846320511c34196--