> -----Original Message----- > From: Andrey Andreev <n...@devilix.net> > Sent: Tuesday, February 5, 2019 5:18 AM > To: Zeev Suraski <z...@php.net> > Cc: Dan Ackroyd <dan...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
