On September 22, 2014 4:21:29 PM CEST, Rafael Kassner <kass...@php.net> wrote: >IMHO, denying non-karma people to vote is like to making PHP a >company's >product, or, in another words, "you use what we built and shut up", >because >only listening people won't allow to accept/deny a particular RFC, only >votes do. People surely don't comment (myself included) why they are >choosing some particular option on a RFC, but they are making their >opinion >count, and I think this kind of "democracy power" shouldn't be voided.
Slightly provocative: Why should I be forced to maintain code by people who don't want to maintain it themselves? Probably even due to votes by people about whom I don't know anything? Mind that most maintenance work by most contributors happens in free time on a voluntarily base. And no open source doesn't mean democracy as governing model. The democratic part is that people who don't like it can fork the project and eventually receive a higher traction. But no, "one man one vote" and full equality doesn't work out. (i.e. if a modules primary maintainer vetos a change I have to mind that [which doesn't mean I have to agree in the end]) >Using separated voting count isn't an option? Like only internal >changes >are voted only by people with karma and features/changes/small BC >breaks >that affects userland are allowed to anyone. This way I believe is easy >to >say if either internals and community agrees with the proposed change >and >community people are making their opinion count. There are no plans (and enough people who'd veto such plans) to close the mailing list. Everybody might state their opinion and we are happy to receive (constructive) feedback and ideas here. And yes, this can be a bit painful due to different forms of "trolling" but leads to better results respecting more opinions than a yes/no vote. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
