This is truly developer way. :-) On Feb 5, 2019 01:10, "Christoph M. Becker" <cmbecke...@gmx.de> wrote: > > On 04.02.2019 at 23:59, Kalle Sommer Nielsen wrote: > > > Den søn. 3. feb. 2019 kl. 19.29 skrev Larry Garfield > > <la...@garfieldtech.com>: > > > >> To answer both you and Sanislav here together, as he raised a similar > >> point, > >> that presumes that 100% of the "invited outsiders" vote on every RFC. I > >> think > >> that is unlikely, although I freely admit I have no real data to speculate > >> either way. Lacking any other evidence I'd say it would probably follow a > >> similar pattern to Internals day. (If we assume a 175 person voting pool > >> and > >> a turnout of about 50, then that's in the neighborhood of 25-30%.) > >> Truthfully, though, none of us have any idea what the total impact would > >> be. > > > > As a continuation of my answer above to this one; By looking at the > > average turnout of people voting as it is now, there is a 50%+ of > > people with just doc karma in one way or another (single translation), > > just PEAR or even some without any form of karma voting. Looking at > > the list of the 175 or so posted, it is a very small margin of those > > on average that votes for RFCs, meaning that adding externals to the > > top of that, that number in my original email is gonna be a lot larger > > and therefore a lot more dangerous if we open the floodgates like > > that. > > In my opinion, the question “who is eligible to vote” is closely tied to > the RFC *at hand*. For instance, str_begins() wouldn't be much of a > maintainance burden, and whether it should be included into the PHP core > could very well also be decided by some of those who won't contribute to > the implementation/maintainance. On the other hand, whether to add JIT > compilation may better only be decided by those who would have to > maintain the implementation and who can assess related issues and > pitfalls (I'm none of those), but not by those who only can fancy “hey, > JIT is cool – let's have it!” It's obviously hard to lay down > respective rules, though. > > Anyhow, instead of suggesting some “general improvements/refinements” to > the RFC process, in my opinion, we should identify *where* exactly our > RFC process has failed, and *why* it did so. Then we should eliminate > the bugs (if there are any). > > -- > Christoph M. Becker > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
