Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85352
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CABDNdAFS=rDpBgPJPYKZ+7mWCUtyam=y3ude9QEdnmis08U-7w@mail.gmail.com>
References: <CABDNdAFS=rDpBgPJPYKZ+7mWCUtyam=y3ude9QEdnmis08U-7w@mail.gmail.com>
Date: Sat, 21 Mar 2015 13:30:39 +1100
Message-ID: <CAEZPtU4CTEZSPG7By5t-N5eLY+D==Vk5AuZg5v3GzkgLwWGACg@mail.gmail.com>
To: Philip Sturgeon <pjsturgeon@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Only Vote on Votes Initiated After Registration
From: pierre.php@gmail.com (Pierre Joye)

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