On Mon, 4 Feb 2019 at 23:46, Zeev Suraski <z...@php.net> wrote: > > I've been doing a horrible job at explaining myself if that's what you think > I'm trying to do.
As I said before, I think the difficulty has been caused by presenting a complete set of solutions to multiple problems at once, without agreement about what the fundamental problems are. If you want to progress this RFC (or any RFC for that matter) breaking the whole problem down into individual problems, and then talking about those is usually more productive and less likely to produce drama than just introducing a proposed solution. I'm going to break what has been talked about in this discussion even further, as I think we're still talking about solutions without agreeing what the actual problems are. 1. No process for giving vote to userland users. Although that was proposed in the original voting RFC, I disagree with this being a big problem that needs solving now. The people who are voting are also userland users of PHP, and a lot of us use the libraries/frameworks that would be given a vote. Even here, the issue isn't necessarily one that would be best solved with giving people a vote. I think a better solution would be to make it easier for people involved with userland libraries/frameworks to give feedback about RFCs. Something like making a space on the RFCs form for userland libraries to place their feedback, so that it is easily visible to all voters, rather than being tucked away in an email thread. I strongly doubt that if the feedback from multiple userland libraries was "this is a terrible RFC and will cause us lots of problems", that those opinions would be ignored. 2. Who can vote needs to be tightened. While I can agree with that, i'm not sure how big a problem it has been. I haven't seen many votes where the margin of the decision has been decided by less than the number of non-core developers voting. Exactly who can vote is likely to be a big sprawling discussion that's going to drag on for quite a while. Although 'anyone with a php.net account' may not be ideal, it has allowed extension maintainers, documentation writers and other people who don't meet the 'core contributors' test, but who have otherwise contributed to PHP to have a vote. I'm pretty sure those people should still be covered by any new rules.* Discussing that separately from other topics is likely to be a better way to proceed. 3. Once given, a vote stays forever, which is probably inappropriate no matter how the vote was attained. I think I can agree that people need to be actively contributing to PHP to be able to continue to vote. Even if someone commits a lot of code, but then doesn't contribute for five years, why should they continue to be able to vote? However that sounds like it is going to need to have a tool built to track voters registration, which sounds like a decent chunk of work to build and operate. Depending on the rules chosen, we might also need an 'appeals' process for people who either feel that some of their contributions have been missed, or who have done major contributions that don't fall under the exact rules.** cheers Dan Ack * Full disclaimer, I meet the suggested 'git commits to core' to retain a vote. If I didn't and the work I have done on extensions didn't count as a good enough contribution, I would find that very annoying. ** For example, there is a project to move the source for the php documentation from SVN to git, which is a non-trivial undertaking but is hard to measure as a contribution in 'lines of code'. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
