On Mon, Feb 4, 2019, 7:18 PM Andrey Andreev <n...@devilix.net wrote: > Hi, > > I was avoiding this, but since the discussion has already turned into > all about who gets to vote, I might as well ... > > On Tue, Feb 5, 2019 at 1:46 AM Zeev Suraski <z...@php.net> wrote: > > the barrier to obtaining a vote is ridiculously low. > > You keep saying that, but it hasn't been explained how it is so. > > 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. > > 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. > > 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. > 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. > > 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. > Some squash commits, some don't; I've had my own commits squashed AND > 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. > > 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. > > Cheers, > Andrey. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
Stripping any existing contributors of our voting rights is a non-starter for me, period. Any changes must not be applied retroactively, as that would just lead to all kinds of problems and severe animosity/drama. The eligibility needs to be moved to its own RFC and fixed so that it doesn't overreach by trying to force out existing voters. Otherwise you can count me as a firm "no" on this one. > >
