Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104160
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=JMEh+dW00dU09iAgraKFE4TW3KyhGeLK/I2DxPanv6ZCMvNpeSpYYiCxzdsRwB
	X7/4TrwAqHPu4t7qHnITXuHCegWki0LBlnMBlXxhgXUfvebJRBLMQBsO8WY0phDX
	EhxjIxBcndf+ws+powIaMdzf98LskjFJRZwM4ieQh7KQY=;
MIME-Version: 1.0
References: <03f401d4b96b$18b9dc60$4a2d9520$@php.net> <CA+kxMuTpM=kfLFUtxRY57eWT3N6jx2A9m7MumbSDj=OPuXcdAA@mail.gmail.com> <CAJHtznyqZOribu8iyat0i6kQdyyoFEf_jy0GgRy2cH3GWMB4xg@mail.gmail.com> <CA+kxMuRdYkACvRFKes9v95MLhR1dwOFwpYUuBFfFARHq5_BUyA@mail.gmail.com> <092c01d4bce3$d8e82e80$8ab88b80$@php.net> <CAPhkiZxSfiSsBF4=O+PeJoKmYXj7RDQYfMAqcnoihzj9vge_vg@mail.gmail.com>
In-Reply-To: <CAPhkiZxSfiSsBF4=O+PeJoKmYXj7RDQYfMAqcnoihzj9vge_vg@mail.gmail.com>
Date: Tue, 5 Feb 2019 10:36:48 +0200
Message-ID: <CAJHtznzn9Qm7RFpLUkCDhSBzcFADf2nD7h+X1MA8AekHjnBkKg@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>, Zeev Suraski <zeev@php.net>
Cc: Dan Ackroyd <Danack@basereality.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: RE: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)
From: zeev@php.net (Zeev Suraski)

> -----Original Message-----
> From: Andrey Andreev <narf@devilix.net>
> Sent: Tuesday, February 5, 2019 5:18 AM
> To: Zeev Suraski <zeev@php.net>
> Cc: Dan Ackroyd <Danack@basereality.com>; PHP internals
> <internals@lists.php.net>
> Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)
>
> You keep saying that, but it hasn't been explained how it is so.

It's simple.  It's very easy to get a VCS account.  You basically just ask,
and if the request is reasonable - you'll get one.  It's enough for one of
the folks who have admin rights on master.php.net to think that the request
is reasonable for them to grant it to you.  That's it.
You may consider that a reasonable bar, I don't.  Nor was this ever a
bar agreed upon by the developers.

> Is it the PEAR-only contributors that you want to eliminate? The doc &
> translations teams? Old-timers who are no longer interested in the
> project? Is
> there a common occurrence of existing leaders granting VCS accounts to
> friends
> for no reason?
> I mean, if you want to reduce thousands to sub-200, you might as well put
> down
> all your cards.

My cards are simple - the current de-facto bar is not sensible.  It was
never intended.  It is not backed by anything the code contributors ever
agreed to.  It has no parallels in other OS projects.  It stems from one
source and one source alone - it was the easiest way to get the voting
process up and running in a fully automated way.  It would effect many
sub-groups, but the idea isn't about who to exclude, but rather - who to
include.  It includes those who have contributed to the PHP project itself,
have made a sizeable contribution and over a period of time.  Exactly like
it is in mostly every other open major source project (at least one that has
no BDFL(s)).

> Aside from a couple of past cases where "ghost" voters were mobilized for
> a
> huge, controversial RFCs, I haven't seen a problem with the current voting
> pool
> members (and thus see little reason to attempt to change it), but I also
> think it's
> sensible that e.g. translating a couple of lines in the docs isn't enough.
> In any
> case however, the criteria and metrics that you've chosen are, to me,
> quite
> arbitrary and only appear fair while not actually being so, especially the
> 25
> commit count.

We can (and should) debate the criteria.  The rationale was to have bars on
both the contribution's size, as well as its breadth.  The number of commits
tended to correlate with contributions over time, as opposed to one-time
contributions.  There may be better ways of determining that, I'm open to
suggestions.

> Full disclosure - that last one is what disqualifies me. Although, I
> certainly don't
> consider myself a "core" developer, so if your intention is to limit
> voting power
> to only that group I guess it has achieved the goal in my case.

Well, honestly, I don't think the 25 commit / 500 line bar qualifies anybody
as a core developer, and that's not what I'm trying to establish.  It was
actually purposely what I at least consider a very low bar - that allows
newcomers to become voters relatively quickly (within several months to a
year), by showing a certain level of interest and commitment.

True core developers clear bars that are two orders of magnitude
larger, as you can see for yourself in the Git statistics.

> On the other hand, I qualify under all the current status-quo criteria
> - I've contributed some code, features, tests, docs; had a couple of RFCs;
> am a
> lead framework developer; participate somewhat regularly in internals
> discussions - yet obtaining voting privilege wasn't as easy as a
> "ridiculously low
> bar" would make you believe.

Regardless of what you did, actually obtaining full voting rights
meant you had to ask for a VCS account, and have a reasonably good
explanation on why you need one - enough to convince one of the folks
with admin rights on master.php.net to click the 'Accept' button.
That's all.  Immediately, one has identical rights to someone who may
have been spending years of their time on PHP, in a one way ticket.

Setting certain bars on the ability to influence the direction the
language is going does not in any way take away from the work you or
others did.  PHP benefits greatly from contributions of hundreds of
thousands of people in various fronts.  The vast majority of those
don't have voting powers today, including ones that have similar (or
different but equivalent) credentials to the ones you mentioned, but
didn't apply for a VCS account.  Whether or not we should provide
non-code-contributors with voting rights is a tough question (as can
be seen on other posts on this thread), but I do think that the 'base
group' of those who should have voting powers should be the code
contributors - and we therefore need some definitions on what
qualifies one as a code contributor.  Including other criteria (such
as tests, docs, framework contribution, etc.) is probably not
feasible, as it would be very difficult to apply in an even manner
(and no, what we have right now absolutely does not apply it in an
even manner).  It may be that the code contributors (as we end up
defining them) could have a process to invite/elect non code
contributors as voters (temporary or permanent), or, as others
suggested, simply rely on non-code-contributors participating in the
discussion, and code contributors representing them in their votes.

> Anyone who has ever attempted to use such metrics for evaluation would
> tell
> you that commit count is a horrible one. It makes no difference between 25
> and
> 25k lines, quality or significance.
> It doesn't give any weight to participation in discussions either, whether
> its on
> this list or code reviews, both of which I believe are influential and
> valuable.

As I mentioned above, the criteria is open for debate.  From my POV
though, having such a criteria and implementing it - even if it's 7.5
years too late - is a must.
I agree that a commit count isn't a good criteria on its own, but as
mentioned above - I think it adds value as an added bar for the
already-low 500 line count.
I consider both criteria as fairly low bars for full voting powers on
one of the most popular open source projects in the world.

That said, moving to a single criteria based exclusively on LOC is
also a possibility - although in such a case I'd go for a higher bar
than 500 LOC.  Here's some experimentation:

sqlite> select count(*) from gitstats where insertions>=500 and commits>=25;
180
sqlite> select count(*) from gitstats where insertions>=500;
282
sqlite> select count(*) from gitstats where insertions>=1000;
228
sqlite> select count(*) from gitstats where insertions>=2000;
174

You can also experiment with it yourself:
https://www.dropbox.com/s/487bkzz1ukhxjhp/php-src.sqlite

Also note that the 'Grandfathering' period aims at providing a
reasonable transition for those who are borderline qualified to vote,
and gives them a full year to clear the bar to retain their full
voting rights.

> Some squash commits, some don't; I've had my own commits squashed
> authored by the person who merged them, meaning my name isn't attached to
> them at all. This is an example of a previously meaningless factor all of
> a sudden
> becoming a deciding one.
> There are some well-known names that don't make the cut in Appendix A and
> that does raise an eyebrow.

I've had one person ask me about that exact same topic.  What should
matter is the substance - and not what the automated scripts tell us.
I believe there will be several cases such as yours, where the dry
stats don't qualify you but the actual stats do.  What would matter is
the latter - even if we need to do a bit of manual work in the
beginning (the list of voters won't be just 'calculated' from the
gitstats;  It would feed to it, but we would also have some manual
override).

> If you want to say that there are people with voting privileges that
> haven't
> earned them, that's one thing, but (and I'm not assuming bad intentions
> with
> this) as it stands it looks like you just wanted to cut as much as
> possible and only
> looked for a metric that wasn't going to eliminate the very top
> contributors,
> whom you can't afford to lose.

Again, I don't consider 500LOC / 25 commit as the 'very top
contributors' (especially on the LOC side).  The variance in
contribution between these ~200 folks who qualify under this criteria
is huge.  Had we wanted to go only for top contributors, we'd be left
with a lot fewer people (e.g. increasing it to 10K LOC cuts the list
in half)  The criteria is supposed to be very achievable.  I reran the
stats, and in the last 17 months (since Sep 2017), 5 additional people
cleared these bars, which I think is a very reasonable pace.

Zeev