> -----Original Message-----
> From: Derick Rethans [mailto:der...@php.net]
> Sent: Monday, September 22, 2014 2:33 PM
> To: Andrea Faulds
> Cc: PHP internals
> Subject: Re: [PHP-DEV] Is it fair that people with no karma can vote on
> RFCs?
>
> I think people's votes should only count if they have karma to the section
> of
> the code that the RFC/feature/whatever relates to.

I agree with that, to a degree.  I think it depends on whether we're talking
about implementation RFCs or feature RFCs.

As I mentioned in the past, when the Voting RFC was written  - I never
envisioned it would be used for implementation decisions.  Maybe it was
short sighted, maybe not - but to me, it was obvious that implementation
would be up to the respective code owners, and not the full voter base.  So
yes, implementation issues that deal with the engine should be decided by
those who have engine karma.  Implementation decisions to the mysqli
extension should be up to those who contributed to this codebase, even if
there's just a handful of them.  And so on and so forth.  Johannes recent
comments about maintenance of code are a major reason behind this approach,
but it goes beyond fairness.  The contributors are the domain experts in the
respective implementations - it makes no sense to open this up to the voter
base at large.  You want to have a say?  By all means, work your way in and
contribute;  Once you do, you'd have a vote.  Until then, you have a voice
in internals, but not a vote.

The second group is trickier - and those are language features and other
types of votes.  The way we work today - where SVN yes/no is the only
question - was absolutely not the intent of the Voting RFC and thankfully,
it's also clearly not the language it contains.  The original RFC read the
following:

* People with php.net SVN accounts that have contributed code to PHP
* Representatives from the PHP community, that will be chosen by those with
php.net SVN accounts

Unfortunately, this was changed without me noticing it at the time, to the
following:
* People with php.net SVN accounts that have contributed code to PHP
* Representatives from the PHP community, that will be chosen by those with
php.net SVN accounts
  * Lead developers of PHP based projects (frameworks, cms, tools, etc.)
  * regular participant of internals discussions

The first bullet is the one this thread deals with so far.  It clearly
states that having an SVN account isn't enough - but that code contributions
to PHP are mandatory.  We should probably consider revising that to also
account for people contributing docs and other types of submissions.  I'd
also consider adding a requirement for contributing at least X commits (say
20 or 50) so that someone who did a one-off or two-off patch won't have the
same vote as someone who contributed  hundreds or thousands of commits.  I
believe this data can be easily pulled from git.

While we're at it, IMHO, the second bucket is open ended and must be much
more well defined.  I think we need a process where people from the
community can be nominated and voted on - either by people from the first
line, or by some sort of a public community poll.  Having 'elections' for
representatives from the community doesn't sound like a bad idea to me :)
Another option is to take the 1-2 top contributors of the 10-20 top PHP
projects on github.  That's probably a lot easier and would eliminate much
of the politics involved.

Last, the 2nd sub-bullet of the 2nd bullet ("regular participant of
internals discussions") is especially problematic - as it basically pulls
the barrier to entry to nothing, and is the opposite of well-defined.  When
we revise the Voting RFC, it should go IMHO.  Talk is cheap - the way to get
a vote with PHP is to contribute - be it with code, docs, testing,
frameworks or apps.

Zeev

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to