Den søn. 3. feb. 2019 kl. 19.29 skrev Larry Garfield <la...@garfieldtech.com>: > > It's not absurd, it's a matter of degrees. As Zeev noted in a later email, > the current voting RFC already calls for some voting-level input from "major > customers", but not a controlling vote. > To use hyperbolic examples: > > Would adding one single non-C-developer to the voting rolls mean that "the > Core Developers have to maintain code that is decided by external, non > contributing parties"? No, that's "kinda absurd" to call it that, because > that one voter is clearly swamped out by the many other Internals developers > that are also voting.
You and I both know the average turn-out of people voting here on RFCs, that I do not doubt you follow in anyway and then you know that if we add that top plus additional projects not represented under the FIG, then that is a large deciding factor and don't tell me that everyone who could get the ability by getting a vote won't be doing so for at least the first long while. I do believe it will decrease over time yes, but anytime soon if it passes. > Would adding 200 non-C developers to the voting roll mean that? Certainly > yes, that would be an absurd situation. But no one that I've seen is > suggesting that at all, or anything close to it. There has to a limit. Whether it is 1 or 200 or even 1000 doesn't matter. As long as it is more than 0 externals that has a direct deciding factor for a change. There is a fine line whether a non project member should have a say in the voting which is apart of our project management over actively listening and engaging with the community and taking that feedback into shaping PHP. The line I'm trying to write here in bold is that having a say doesn't mean voting power by any means. If you as userland believes that we as the language project do not include your feedback, then let's have a discussion about that in a thread and look at how we can make a more engaging and open way to actively work on what the community would want to see coming into PHP. I do not believe influence should be linked to voting power within the project by any means, that is one of my main arguments against this. > What's the threshold of absurdity here? That we could debate. However, it is > not 0. (I'd personally put it in the 10-20 range, bearing in mind that not > all of them would vote all the time anyway, just like core developers, but > others may feel differently.) As long as a non project contributor, as have the power in the form of being able to vote and therefore directly affect the active ones. That is my threshold of absurdity and in a way I'm baffled that you do not seem to understand that. > 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. > That same point applies to any "invited outsiders", whether that's done > through FIG or otherwise. Per Zeev's email, it does seem like some mechanism > for invited-outsiders was always intended, even if it never materialized. Back then I was also against that, and I'm happy it didn't materialize further on the voting aspect. This gives us a chance to clean this system up and streamline the processes. > To clarify: I last wrote C code in 2004 for Palm OS. I am quite rusty; on top > of that I know just enough about Internals to say that it's not as much > written in C as it is in a macro language built in C, so the learning curve > would be rather high. My personal lack of involvement in actual Internals > code is mainly because the logistical barrier to re-learning enough tooling > and language to do so is too high given that I have no professional > justification for it. I try to contribute to the PHP ecosystem in other ways > instead, internals or otherwise. > > Whether or not I am personally impacted, though, I do feel and have long felt > that a more direct mechanism for user-land developers to have some influence > on PHP would be beneficial. (Though, yes, considerably less than the direct > contributors working on the code base, who should still be the predominant > constituency.) That I do agree with. But like I mention above in the reply, I do not believe that influence should be on the behalf of voting power. The PHP community is large, exceptionally large and while I wish there were ways was more open for developers to join the "conversation", I do not see how we can start tackling that, which itself is perhaps a topic for another thread on its own. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
