Re: RFC: RFC Workflow & Voting (2019 update)

On Friday, February 1, 2019 7:11:40 PM CST Kalle Sommer Nielsen wrote: > Den fre. 1. feb. 2019 kl. 02.42 skrev Larry Garfield > > > So I would support a mechanism of some sort to give formal voting rights > > to > > non-internals-C-developers who are still significant-PHP-contributors, as > > long as the number of people involved is relatively low compared to the > > direct- contributor number. With a contributor voting pool of ~175 > > (which would no doubt vary but let's assume stays in vaguely the same > > range), an "at large voter" population of 5, 10, or 15 people would > > provide direct representation without a meaningful risk of swamping the > > direct contributors, who I agree should remain the overwhelming majority > > of eligible voters. > > So while you fully agree with its a bad idea that us the Core > Developers have to maintain code that is decided by external, non > contributing parties, still you think there should be a way for non > Core Developers to vote? That is kinda absurd. 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. 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. 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.) > > This would be the first formal recognition of FIG by PHP Internals. I am > > completely OK with that, and personally would love to see Internals and > > FIG > > collaborate more; I'm just noting it for completeness. > > I'm not okay with that at all. I accept and respect what you as a > project do, but because of that it doesn't mean you (you as in a > project) should have a special right over our project because you > represent some of the most used userland projects. Besides the very > high profile projects like Laravel and Symfony (even projects like > Doctrine and Guzzle) is no longer represented, WordPress is not even a > part of the FIG. The degree to which "participation in a big name project" correlates or has a causal relationship with "is a significant voice and influencer in the community" is a contentious question, and one that FIG has debated for years. Without going too far down that rabbit hole I will only say "it's very complicated" and not cut and dry either direction. > Given the volume of people who currently votes on RFCs on average, > that would literally mean that we would increase our average voting > pool by 25%, something to consider as by then the FIG would > essentially sit with about a 20% say in whether or not something > should go in and their hands will stay clean because we as maintainers > will have to do the dirty work and that is without projects like > Laravel, Symfony and WordPress having a say, just the FIG. 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. 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. > > (Disclosure: I am a member of the Core Committee so that would include me; > > I hope that doesn't itself turn anyone off of the idea :-), but I mention > > it for transparency and feel it would be a good approach even if I > > weren't.) > That itself worries me, because you are represent a part of the > community using the language, but you are not a language designer. You > are active with input on internals and RFCs etc, which I respect a > lot, but without any interest in actually writing code (I can't really > say if its true or not regarding the interest or its because of C > know-how) or because of time schedules like we all have, I don't see > why a special exception should be granted. No offense. 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.) --Larry Garfield

Attachment: [application/pgp-signature] This is a digitally signed message part. signature.asc