On Thursday, January 31, 2019 12:17:02 PM CST Chase Peeler wrote: > On Thu, Jan 31, 2019 at 11:52 AM Zeev Suraski <z...@php.net> wrote: > > On Thu, Jan 31, 2019 at 5:58 PM Kalle Sommer Nielsen <ka...@php.net> > > > > wrote: > > > Hi Zeev > > > > > > Den tor. 31. jan. 2019 kl. 15.44 skrev Zeev Suraski <z...@php.net>: > > > > Without further ado, an RFC that’s attempting to comprehensively solve > > > > > > many of the issues that have plagued our RFC process since it was > > > hastily > > > > > > introduced in 2011: > > > > https://wiki.php.net/rfc/voting2019 > > > > > > I wholeheartedly disagree with the PHP-FIG special exception to who > > > can vote, call me biased but I do not believe it serves any purpose > > > and is absurd. People who actively work on PHP, should be the ones to > > > be able to have a choice, I think that should be reserved for any > > > contributor who puts effort working on PHP. > > > > > > I do understand that we are the language and our work affects the > > > others the most. However making special exceptions for who can vote > > > and essentially having a say from an external source in what I in > > > theory need to help maintain as a PHP Core Developer is terrible. Why > > > not allow WordPress Core Developers to have a say instead, as their > > > work has a larger impact on the usage of PHP? (That was obviously a > > > bit of sarcasm, the last part). We are not allowed to vote at their > > > individual projects features (nor do we need to have a say if we are > > > not actively involved in the development of said projects or > > > organizations) and I stand very strongly behind that belief. > > > > That's a very fair point. I'm personally undecided on this. It's fair to > > say that in 2011, my thinking was that voting rights should be given > > pretty > > much exclusively to contributors. It may sound like overreaching, but the > > reality is that this is pretty much how ALL open source projects work (and > > have been working). The reason it sounds overreaching, is that over the > > several years following the ratification of the 2011 Voting RFC - a status > > quo of "virtually anybody can vote" took hold, and it's now fairly > > entrenched in people's minds. It's still very, very awkward when taken in > > the context of how OS projects behave in general. > > The thinking behind PHP-FIG (and for that matter, having some > > representation from WordPress, yes, I'm not kidding...) was to create > > something which goes a bit farther than what's usual in an OS project - > > because of the status quo we have today. Making it a bit easier to > > digest. But it may be that it's the wrong approach. I'll be interested > > to > > see what others think about it as well. I'm personally open both for > > extending that list further - or potentially trimming it down - making it > > more of a meritocracy, as is customary in virtually all other OS projects. > > > > I don't know if there is a good way to implement it, but I definitely > > think there is value in some sort of voice being given to those that use > PHP to build things, but don't contribute to the actual source. > > I think it's important, though, to make sure that developers that are out > there actually developing things with PHP (not to say that contributors > don't belong to that group) have a voice - I'm just wondering if that needs > to be defined in a more formal way. One statistic I just found says that > almost 6 million websites are running PHP7. Even if we assume that it > averages out to where there is 1 developer for every 100 sites, that's > still 60,000 developers being represented by 175 voters. > > Maybe the voice that we currently have in the form of being able to > participate in these discussions is enough. I'd be interested in knowing > how often voters are persuaded to take a position on an issue after > discussing it with non-voting developers - whether via these discussion > lists or on other mediums. > > Maybe instead of giving all members of PHP-FIG a vote, the RFC can be > amended to specify that PHP related groups with a certain number of active > members are given a single vote. Or, instead of membership numbers, an > application process of some sort can be put in place for various groups to > petition for representation. If accepted, that group is given a single > vote. A committee can be put together that is in charge of addressing the > applications.
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. 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. 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. 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. (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.) 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. 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
signature.asc
Description: This is a digitally signed message part.
