Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104285
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=nw8KuJuaB3zUBKTR8SkX/Lm2VbYmBKjFKQCcUal3sWOq25Jn5scJ0vTyXfn6CZ
	2qjlKxGQ0E+SGySy+cwpUkznsjk8msGpJYWrtDBrM5J9TYjLQ66A/ZkeSAEg2ZRd
	YgmPK/enali7iT7V2zMsOMYO/Zf3ClTp92NpNu82MIZjU=;
MIME-Version: 1.0
References: <CAOwTYAsePeRLZZVK=QKftoOtug2_F=5bsti56z2mJfBXP0u4rw@mail.gmail.com> <CAF+90c8_LqpqBwsPtFnomdEOXniUGFY4UELG2bHQzPCrr19Fhw@mail.gmail.com> <CAJHtznwD9K=zhafYOpdGx6CZWX9Rejd_n9ffzgw4WUU6spwx-Q@mail.gmail.com> <CANUQDCjrXm-4kLQUfFA4yzsk50_aMwt8GY0bNnHiaTyBRkbTCw@mail.gmail.com> <CAJHtznxzxzNfGs2cpcvcpGyjddt-QA+ho3b4vNd=SLyz0T4czw@mail.gmail.com> <CAEZPtU5EXPSfUvSGh888BJwP=DiH-7fS8Awy0d+Ya-jcxpfGdA@mail.gmail.com>
In-Reply-To: <CAEZPtU5EXPSfUvSGh888BJwP=DiH-7fS8Awy0d+Ya-jcxpfGdA@mail.gmail.com>
Date: Thu, 7 Feb 2019 14:37:12 +0200
Message-ID: <CAJHtznw+C6=rVeaERbRLCFLap1LnkgUBHBznFfYaCaTeGpQS_g@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Niklas Keller <me@kelunik.com>, Nikita Popov <nikita.ppv@gmail.com>,  Joe Watkins <krakjoe@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ad59f305814d1af1"
Subject: Re: [PHP-DEV] RFC Abolish Narrow Margins
From: zeev@php.net (Zeev Suraski)

--000000000000ad59f305814d1af1
Content-Type: text/plain; charset="UTF-8"

On Thu, Feb 7, 2019 at 10:42 AM Pierre Joye <pierre.php@gmail.com> wrote:

> On Thu, Feb 7, 2019 at 3:39 PM Zeev Suraski <zeev@php.net> wrote:
>
> >  It has to do with the relative power
> > of the code contributors, vs. folks who aren't code contributors who
> > presently have a vote even though they're not supposed to have one based
> on
> > the rules agreed upon back in the day.
>
> This is not correct. I am not sure you read my other reply in the
> other thread (please do if not).


I read it, and I didn't find anywhere something that contradicted this.


> The "must contribute code to have
> rights to vote" is not what we tried to achieve.


Nor is it what I'm presently trying to achieve either (at least that's not
my preferred outcome at this point).

Again, there are two categories of people defined as eligible voters:

First:
"People with php.net VCS accounts that have contributed code to PHP"
The intention here is quite clear.  People that have contributed "code to
PHP".  Specifically, it's clearly a qualifier for "People with php.net VCS
accounts", i.e., this is a subgroup of those who have VCS accounts -
specifically ones that have contributed code to PHP.

Second:
"Representatives from the PHP community, that will be chosen by those with
php.net VCS accounts

   - Lead developers of PHP based projects (frameworks, cms, tools, etc.)
   - regular participant of internals discussions"

The intention here is also quite clear - add non-code-contributors to have
votes as well.  However, in terms of how we do it - it's awfully laconic
(to be honest I never expected it to just pass as-is - it was roughly at
the qualify of a first draft - but it did).  The intent was to have some
sort of representation of the outside world in the actual votes (and not
just in the discussions), instead of having only the code contributors
eligible for voting.  The intent was still very much to keep the balance of
power such that the actual code contributors would have most of the say -
as the word 'representatives' implies.  However, we never went ahead with
the process of choosing these folks anyway.

So while I completely agree with you that we didn't try to achieve a "must
contribute code to have rights to vote", we did try to achieve a situation
where those who contribute code have (as a collective) the most influence.
And we certainly didn't try to achieve a "having a VCS account gives you a
vote".  The 2nd group never materialized - we never went through any sort
of process of choosing representatives (mainly because there was no such
process).  The first group was mis-implemented because it was simple to do
in the Wiki - and the rest is history.

I still think that at a fundamental level, what we agreed on in 2011 makes
sense.  The core group should be those who contribute code to PHP
(potentially including PECL).  On top of that - we need to either figure
out the mechanism that we neglected to specify back in 2011, or give up on
it officially.  As I mentioned previously on this thread - I'm undecided on
this matter, but primarily because I'm not sure what this mechanism could
look like (even though I have some thoughts on the subject).  If we can
come up with a good mechanism - I think it's generally a good idea.

Zeev

--000000000000ad59f305814d1af1--