On Mon, Mar 16, 2020 at 8:20 PM Dan Ackroyd <dan...@basereality.com> wrote: > * Explaining exactly why you're voting no can be hard as there can be > multiple overlapping reasons for voting no. > > * It sets up arguments about what is and isn't a valid reason for voting no. > > * It drives people who might want to vote no away from the project, if > they have to take the extra time to justify their position. Maybe a list of standard answers to choose from could be a good compromise: - Don't like the syntax - Don't find the feature useful - Limits future changes - There are better solutions - Is complicated to implement - Breaks backwards compatibility - Prefer not to say
All are valid reasons for voting no. If there are multiple applicable reasons, just pick one. Or allow picking multiple? If having to pick one of these is enough to drive people away, maybe it's for the best... ;-D > For some RFCs, there just isn't a good path forward for them. Even so, giving a reason for voting no will make that much clearer, and maybe stop more RFCs in their tracks. > btw I think there's a bigger problem on some RFCs being accepted, > particularly where people who aren't core maintainers are voting on > things that really need an informed understanding of internals. True, - but likewise, there are purist who don't use PHP in the real world and reject something pragmatic because it's not fancy enough. It's important to be humble in a democracy. Best regards, Jakob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
