On Thu, Jan 31, 2019 at 11:57 PM Stanislav Malyshev <smalys...@gmail.com> wrote:
> Hi! > > I haven't fully read the RFC yet, so I'll come back with more formed > opinion about it probably, but wanted to comment about a couple of > points here: > > > Reasoning: If somebody is out of the project for 10 years they probably > > lost track on how the language and needs evolved and just voting since > > an old friend needed a deciding vote is bad. > > I agree, though "out of project" can differ... But I think if the person > had made no contribution for a decade, then probably he wouldn't be very > well informed voter. Easier way would be to make the list of such people > and let them ask on the list that their vote will be kept if they want > to, with explanation on how they plan to continue contribute (we don't > have to require actual contribution, just people promising to do so - we > are all volunteers here anyway). People that have long moved on would > just ignore that, and people who want to come back will do so. > > > For groups like FIG I am uncertain. I think it is a good thing if we > > push more things out of PHP itself into the userspace (JIT, FFI, ... > > allow more and more stuff to be done in userspace) and thus > > coordinating with userspace developers and setting standards and > > interoperability there is good. However it are the maintainers who > > (often voluntarily) have to maintain these things and overruling actual > > maintainers is bad as they lose interest. > > Yeah I'm feeling a bit uneasy about the FIG part too. I mean, having > input from major userspace groups is great. But having input and having > deciding voice is a different thing. Discussion and vote are different > processes, both important but with different results. So I wonder if we > can't find some venue to collect this feedback without having people who > aren't core developers decide for core developers what should they do. > This sounds like something that won't be healthy. > -- > Stas Malyshev > smalys...@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > The more I think about this, the less I like it. According to the page linked to from the RFC, there are 51 current FIG members who would gain a vote. So this RFC would strip most contributers of their voting rights (including me), while simultaneously adding 51 new voters, all from the same external organization (one that has been aggressively gunning for "official" recognition since its inception). In other words, this RFC, in its current form, would have effectively handed control over the entire PHP project to FIG. Though I'm sure it was never the intent, TBH, this does feel like a bit of a slap in the face to past contributors who still have good ideas to offer now and then and should still have a voice. Furthermore, it seems strange to me that a provision with such massive and far-reaching implications would be quietly buried at the bottom of an RFC filled with otherwise popular, non-controversial ideas. There are a lot of people like me who, while we may not be active core contributors, we have contributed in different ways over the years and we deserve better than to be pushed aside like this. I dedicated a full year of my life to this project and made a number of contributions to our test automation during that time, as well as put a lot of time into testing and debugging during the 5.3.3 release cycle. To say that I should be denied a vote now only serves to discourage me from being active again in the future. While I agree that we should tighten-up our standards regarding who gets to vote, I am increasingly convinced that attempting to apply it retroactively to existing contributors at all would be a mistake. It just looks like a solution in search of a problem, seeing as how most of those inactive people don't vote anymore, anyway. Furthermore, having a more diverse voter base that includes people not directly involved with the day-to-day core work helps to prevent any changes that would be wildly unpopular with the community from being rubber-stamped. I'm sorry but I must repeat my request that this provision be removed and placed in a separate RFC. I don't see how there's any way I'd be able to support this otherwise. Are you outright refusing to split it up or are you open to discussing it in light of these concerns that have been raised by myself and others? --Kris
