> On Jun 4, 2011, at 3:07 AM, Pierre Joye wrote:
>
> > On Sat, Jun 4, 2011 at 5:46 AM, Stas Malyshev <[email protected]>
> wrote:
> >
> >> [VOTE] is a good idea, let's make it [VOTE].
> >>
> >>> There is no plugin used for it yet, and that's my problem with it.
> >>
> >> Well, votes aren't announced yet either :) I'll try to get it set up
> >> ASAP and see how it works, before announcing the vote. It looks good
> >> in description at least.
> >
> > Please keep them in the wiki as we planed to do. THere are plugins and
> > it is very easy to manage, allows per section voting etc.
>
> I'm hopeful people will continue to understand the RFC definition:
>
> - RFC: Request For Comments
>
> And while doing so, not revert to a vote (RFV?) simply because discussing a
> topic can get messy. Voting has clear winners and losers with potential loss for
> improvements. That and you must then worry about who can and cannot vote
> (i.e., non-inclusive community). It's rare that we've required a formal vote, so I
> fear we will now implement voting at inappropriate times rather than allow a
> consensus to be reached.
>
> Also, people should be given a reasonable opportunity to offer an alternative
> RFC.
I agree wholeheartedly with Philip - and that does not mean that my intention is to derail a healthy
voting process.
Some of you may have followed the twitter conversation that Pierre and I had at the end of last
week; In my opinion, this dry (or partially wet) run that we had in the last few days of a voting
process pointed to several deficiencies that need to be addressed in the RFC release process that
need to be addressed before we move on.
First, we need to make sure that the RFC is properly evaluated by the members of internals@, and
that there's enough time for the RFC to be discussed here on the list. As Philip pointed out -
an RFC is request for comments, not a request for a vote. This list isn't supposed to become
some sort of a bureaucratic voting body, but where new ideas are discussed, refined, and eventually
- accepted or rejected. I realize that some here are worried that discussions can be endless, but
we shouldn't go for the other extreme of having no discussion.
For this reason, I propose the following:
- There'd be a minimum amount of time between when an RFC is brought up on this list and when
it's voted on (say 2wks). The effective date will not be when the RFC was published on
wiki.php.net/rfc - but when it was announced on internals@, by the author, with the intention of
voting on it. It doesn't matter if the RFC was up there for 2yrs, or discussed 20 times in the
past - if the intention is to go for a vote, there needs to be time for a healthy discussion, as
opposed to just yes/no. This will also allow for people who are attending conferences, are on
vacations, etc. - not to miss an entire discussion/vote.
- The announcement will be done in a way that's easy to flag & follow, e.g. - by [RFC] in
the subject line followed by the title of the RFC. Again, the effective date will start from the
time this email is sent to the list, not any other time.
- Eventually, it'll be up to the author to move ahead and call a vote on the RFC. That means
that if the author feels that there's still healthy discussion going on, he can decide not to
move ahead to request a vote after 2wks, but after 3 or 4wks. On the other hand, if he feels that
the discussion is being derailed - he can always move ahead to a vote as long as the minimum
discussion time elapsed.
- In my opinion, only RFCs with active proposers should be discussed. If the proposer of an RFC is
no longer leading the effort to get this RFC accepted - it should either find a new proposer, or it
should be abandoned.
Secondly - the announcement of the vote - I very much agree with Derick that having someone announce
a vote in a thread of 50 messages (or even 10) messages is impractical. It needs to be a separate
thread, and it has to be clearly marked - a simple subject prefix like [VOTE] followed by the title
of the RFC should do.
Thirdly, there's the voting mechanism itself. The voting experience has to be nicer than
editing a wiki page, I think we all agree about that... The plugin Stas installed gets us something
better than that, but ideally, if we could provide single-click URLs in the [VOTE] email itself for
voting yay or nay that would be great.
Last, we need a predefined time for voting. It too has to be sufficiently long so that everyone has
a chance to cast their votes, and on the other end shouldn't be endless. I think the 1wk
should do.
If there's anybody who feels that the minimum 3wks period is too slow, it isn't. Any
mistake we make can take a decade to fix, because downwards compatibility is such an important
factor in PHP's design goals. Taking a bit of time to discuss the merits and contents of each
RFC is well worth it, especially if we have rules and predefined schedules - so that discussions
can't drag forever.
Zeev