Den fre. 1. feb. 2019 kl. 02.42 skrev Larry Garfield <la...@garfieldtech.com>: > Disclosure: I am a long-time member of PHP-FIG, but I am NOT speaking on > behalf of FIG in this post, only for myself. > > As Zeev noted, I think it's very good to have some mechanism for formal > involvement from people who aren't C coders. Currently, in order to vote > (have a direct impact) you need to be a C developer; you technically don't > need to even know how to write PHP, just C. :-) That's a very different > mindset and perspective than people who write PHP all day, and both are > valuable. The PHP community is much, much larger than the PHP Internals C > developer community. > > At the same time, I fully agree with Kalle and Johannes that it would be a > very bad idea for the Internals/C developers to be "forced" to maintain > something they think is a bad feature because the great unwashed masses (who > by nature don't realize just how terrible an idea is for the parser, for > instance) thought it was cool and trendy. Yet the fact that the unwashed > masses think something is useful is relevant and a point that should be > considered. > > 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. > Whether FIG is the best way to select that community-voter constituency I'm > not sure. Or rather... I don't see any alternative mechanism that wouldn't > involve, essentially, replicating the work FIG has done to determine > appropriate "leading members of the community at large". So if tapping FIG > isn't the preferred way, the alternative would involve, essentially, > duplicating at least a large part of FIG's process. Any project that would like a say in something related to PHP as a language, should, much like yourself, contribute to discussions. We as developers do listen to feedback and take that into account when designing and implementing features for the language, as it is naturally made for our users, we value that input a lot and I use that often as a determining factor to whether or not I vote yes to an RFC, and I'm certain that I'm not the only one that puts personal bias a little to the side in that scenario. > 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 moment we as The PHP Project collaborate with you as the FIG, it means that we will be seen as promoting FIG, and therefore it means there is a certain favoritism towards picking what the FIG does because the PHP project collaborates with them, essentially not allowing competing projects or initiatives to have a space there, or it would mean we also would have to take them aboard etc. That is a mess and something we should avoid and why we do not use others packages and projects for building our own web infrastructure. We need to be neutral and transparent as a project because of the scale that is PHP. > Another point there is that the RFC doesn't specify what "member of FIG" > means. FIG currently has 3 defined groups of people: Secretaries (3 people), > the Core Committee (12 people), and Project Representatives (36 people at > Zeev, which group is intended? > > To provide some insight (with a little over-simplification): > > * Project Representatives are appointed by their respective projects, and are > usually but not always project leads. The bar for membership is extremely > low, by design, and most in practice most project representatives are inactive > 99.99% of the time. > > * The Core Committee is elected by Project Representatives, and are at least > moderately active, much of the time. They're responsible for reviewing, > tracking, and approving PSR proposals, and are supposed to be active > generalist architects. > > * The Secretaries are elected by Project Representatives, and keep the > machinery working but are not involved in spec development. They're basically > FIG's project managers. > > If there's a concern about adding 50 "outsiders" to the voting rolls, I would > propose just inviting the 12 Core Committee members to vote. They're already > elected in an open process to represent/work for the PHP ecosystem as a whole, > with an eye toward compatibility, consistency, and all the same kind of stuff > that Internals cares about. And 12 people would not pose a threat of > overwhelming the direct contributors, especially as a handful of them are > already Internals contributors anyway. Should this insane idea of allowing FIG members to vote pass, does that also mean that the ~175 members of PHP get an equal voting right in line with a so called Core Committee member? I doubt that. Reading the FIG personnel page, I can spot 4 members that currently have voting right because of their contributions to the project. Should this RFC pass without allowing outsiders to vote, that would most likely be down to 2 (Sara and Lukas). Besides that I spot an additional 5 project members that can already vote or have contributed back to PHP by code, obviously I'm only a human so my memory with the names may be vague but there is already a presence because those people are contributors to PHP. In theory you already got a large say in voting on an individual basis, even if the contributions to PHP itself is sparse. 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. What about when your Core Committee members change, that means we need to change karma granted because your process changes? No thank you. > (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. > Any other selection process for outside voters would, I believe, essentially > duplicate what FIG already does. It's better to just outsource that selection > process to a known entity. Any presence from an outside group means we need to have a much different process and a lot more political babble, which quite frankly, most other Core Developers don't really care THAT much about unlike the FIG. Something we shouldn't have a need for, despite (to use your own word), chaotic, nature of how internals is at times. All we want to is to write code and enjoy it like we have done for almost 25 years this year, while the internals is no longer the "closed gentle mans club" as it was when I joined 11 years ago, it still is quite distinct from other OSS projects and one of the reasons why I personally stick around, as I like that spirit the project has, which is why I'm very protective of that as I'm certain you must have noticed. > Again, I'm not speaking on behalf of FIG here in any way, so other FIG members > may have their own views on the subject. > > --Larry Garfield -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
