@ramsey folks that complain about internals voting decisions to their large social audiences, without being willing to get involved in the PHP project itself to get voting rights, are causing harm by vilifying the internals team & creating an "us vs them" gap which may further disincentivise others getting involved.
@danb@ramsey That's fair. I'd counter that the barrier to entry to the "PHP project itself" is, or at least feels, very high. So an argument could be made that either PHP internals needs to be an easier club to get into or that there should be some representation from the larger user community of users who don't contribute code to the language itself.
@EdGrosvenor@danb@ramsey Because this is being portrayed by the people pushing an "us vs them" agenda.
I am the living proof (and maybe even Nikita) that this is horseshit.
I joined the internals mailing list when I was 19, when the signup process was even more broken than currently. Got involved by doing translation and doc works, and then seeing some of the nonsense in the docs started contributing to php-src.
@EdGrosvenor@danb@ramsey And I didn't, and still don't, know anything about email, nor OS, don't use containers or Docker, haven't done a computer science degree, nothing that would give me an advantage in contributing.
I "learned" C by hacking on php-src, reading on stuff when I needed, and just dug through the layers and layers of macros using the little docs we have (less than nowadays).
For reference, the only other programming language I knew (and this is kinda still true) was PHP.
@EdGrosvenor@danb@ramsey So no, the barrier to entry of the project isn't high. I'd argue it's too low. As anyone can just sign-up onto the list and start writing their opinions about what the language should become.
But every single person that complains about it being an exclusive club is not willing to sign-up onto a mailing list and actually provide meaningful contributions to discussions.
The problem is, there isn't just one problem. Internals' structure is just a mess all around, but every attempt to even marginally improve it has been voted down by the arch-libertarian/anarchist wing of the voting pool. It's basically a gerrymandering problem. 😞
@heiglandreas@Girgias@EdGrosvenor@danb@ramsey Oh, definitely. The trajectory has been in the right direction, but the drag from legacy processes, people, and assumptions has been severe.
@ramsey@Crell@Girgias@EdGrosvenor@danb Docs always seemed to be the back door to the project (not meaning that in a bad way, our docs are superb because of that). I always found it frustrating trying to help and getting nowhere.
I’d love to be more involved than yelling on a mailing list, it’s just not always clear short of “help with docs”
@dragonmantank@Crell@Girgias@EdGrosvenor@danb I would like for us to provide a way for folks to get involved in helping with systems, but since this requires a higher level of trust, it’s difficult to find ways to involve people to build up that trust.
@ramsey@dragonmantank@Crell@Girgias@EdGrosvenor@danb even docs has a higher-than-needed entry barrier. XML is not the gold standard in 2023 anymore. But improvements can only be done in small incremental and large restructuring is impossible. Not to mention the "we cannot favor any framework, let's build everything with pure PHP like in 2005" mindset.
@Girgias@ramsey@dragonmantank@Crell@EdGrosvenor@danb your answer here perfectly represents the problem. I didn't mention any replacement but you already have your mind set in NO.
Someone new tries to contribute to the docs, finds it cumbersome and is received with "shut up your opinion is invalid, contribute as is or gtfo. I can do it why can't you l?"
@Girgias@ramsey@dragonmantank@Crell@EdGrosvenor@danb to me the difference is that any project/client/integration/whatever I work on, I don't have to convince anybody that XML is not worth supporting and it's already an agreed mindset. PHP on the other hand is still highly used and powering brand new systems, so much so that I have to refuse work due to the amount of demand
@deleugpn@Girgias@ramsey@dragonmantank@EdGrosvenor@danb Docbook is not some home grown dtd. It's a professional standard that's been used for over 20 years in publishing. I also agree that moving off of it is a non-starter for many reasons.
Thst said, it's also valid that it's not as readily apparent to a new contributor as Markdown or such, and that's a barrier. The answer is better docbook on boarding material for new contributors.
@Crell@Girgias@ramsey@dragonmantank@EdGrosvenor@danb it's not just about learning it. I did learn. I managed to make a few contributions. The system in place is not pleasant to work with. Two things that don't go well together are free labor and unpleasant labor. The fact that it's a 20 year old standard might be a strong sign of outdated solution.
Perhaps there's nothing better out there. I don't know. Why waste my time trying to help when the answer is already no before we even begin?
@Crell@Girgias@ramsey@dragonmantank@EdGrosvenor@danb I would never propose unpleasant work for someone else to do it. There are a lot of people eager, willing and interested to contribute. If I find a $HotNewThing that is pleasant and welcoming to newcomers I would put on the work myself. Maybe I would end up giving up half way through it, maybe I would succeed. Arguing against everything and everyone from day one is internals own doom.
@deleugpn@Girgias@ramsey@dragonmantank@EdGrosvenor@danb Even if you offer to do a lot of the work, it's still a major change for everyone else who works on docs, and requires a lot of build system work by the few people with server access.
Contributing against the grain of an OSS project is hard. It really can only be done by an insider. That is not unique to PHP.
I say that as someone who made a career of being against the grain. :-)
@Crell@Girgias@ramsey@dragonmantank@EdGrosvenor@danb that actually makes a lot of sense and describes perfectly how it feels like the ones on the outside want to help build something they feel is better but the ones on the inside don't welcome the unpleasant work to change and might not even feel like its better. Over time less folks are willing to endure working with the existing system
@ramsey@Crell@Girgias@EdGrosvenor@danb I’d also love to get more involved with testing, but it’s always something that I feel like I hit an operational roadblock doing it. But that could also be a “well find a way to make it better” situation too.
@Crell@ramsey@Girgias@EdGrosvenor@danb Mostly the compilation process, and a lot of the gaps are in extensions with makes that doubly hard for writing good tests since a lot of PHP tests are kinda international tests.
Writing the tests and understanding the test harness isn’t so hard.
@danb@ramsey I'll also add that one person in particular about whom this could easily have been a subtoot has, in fact, contributed at least one PR to the core along with an RFC that was rejected. So it's not exactly fair to say that everyone who's complaining loudly from the outside has failed to ever get involved. Their involvement just didn't count for anything because the vote fell the other way.
@EdGrosvenor@ramsey Just to confirm, my post was not in reference to a particular person but a wider pattern I've seen emerging.
In regards to the barrier to entry, yeah, there's likely some truth to that, it'll always be a hard line to define, but PHP does provide the avenue of "regular participant of internals discussions" for lead project maintainers, which I haven't seen being well taken advantage of by those complaining of process.
@danb@ramsey Admittedly, I don't pay a ton of attention to the fine details, but this is the first I've heard of that particular path to entry. It might be that there needs to be more communication around wanting input from people in influential positions within community projects. If you reserve it for the top dog, they won't likely get involved. Taylor is too busy building. But I'm sure there are influential people in the community who would happily jump into the mailing list.
@EdGrosvenor@danb The internals mailing list and RFC process is open to all. Voting rights are restricted in a fuzzy sort of way; the project knows these need to be better-defined, but we don’t know the best way to go about it. Still, everyone can participate in discussion and proposing changes.
It it documented in the PHP RFC guidance: https://wiki.php.net/rfc/voting#who_can_vote ("Who can vote" section) and I've seen this be suggested when folks ask for voting rights in internals.
@danb@EdGrosvenor Like I said, it’s “fuzzy,” but the important thing is that a community member be an active participant (for fuzzy definitions of “active”) on the internals mailing list before they’ll be granted voting permissions.
@ramsey@danb It might make sense to consider asking every significant project (again, fuzzy, but some metric could be landed on) to nominate a member and fast-track that member to a voting position, contingent on them participating in some reasonable way in the mailing list.
@EdGrosvenor@danb The “contingent” part is the hard part, since we don’t have a level of activity defined, and we’ve not done that for anyone in the past.
@ramsey@danb you could probably leave that to the project itself. They’d want their nominee to be an active participant because it’s in their best interest. So the voting right can sit with the organization and leave it to them who their representative is and what level of participation they require of that representative.
@danb@EdGrosvenor If we were able to set up some kind of governance structure like #PHPFig, then we could have community projects apply for “representation,” which would get them a voting seat, but we’d need to define a level of active participation their voter needs to maintain. They’d be the liaison for the project and would need to participate in discussions relevant to their project’s interests.
@danb@ramsey I am very certain that the majority of PHP users are very happy and incredibly thankful for all the internals people for making the hard decisions for us and making the tools that we use everyday but loud enough as the complaining minority.
@ramsey OK
For the love of God learn #PHP before touching a framework like #symfony or #laravel
There’s a pretty good #laravel learning path at Laracasts that starts with #PHP
@joepferguson In all seriousness, the community could really drive this initiative, if they wanted to. There are plenty of votes they could find to work within the system, and @derickr might be happy to help (so would I).
@ramsey@derickr I feel like based on previous internals discussions that adopting something like Python's is the best course of action. Certainly takes off the NIH bits.
@ramsey the new Default Method RFC is because people want inheritance but are so brainwashed with “composition over inheritance” debate that the only way they can reconcile this is to put implementation into interfaces.
@ramsey The fact that after over a year and a half of @thephpf existence, contributing just over 10 000 USD will still put you in the top 20 financial contributors.
Related: everyone has opinions, but no one proposes solutions nor financing for said solutions.
@Girgias@ramsey@thephpf proposing solutions isn't enough. The entry barrier in PHP is catastrophic at this point and even when a new contributor comes in and try to implement some potential code clean up, internals and voters kicks the guy out
@Girgias@ramsey@thephpf that last sentence can be said for both parties involved on it.
Though only one of the parties is a worldwide programming language that claims to be welcoming and easy to contribute
@deleugpn@ramsey@thephpf Proposing solutions doesn't mean "throw away 27 years of code, frustrate everyone on the project, be annoyed at inconsistencies, insult long-standing contributors".
Do I think overall their changes were good? Yes, but they did do some idiotic changes and throw tantrums for no fucking reason.
@ramsey@Crell Maybe I've missed a lot, I certainly don't follow internal php politics. The repo from derickr you pointed to hasn't been updated in 6 years, which I believe is before the unpleasantness in the Drupal community that revealed the very sizeable holes in the governance process
@Crell@ramsey Understood. I'm reacting, admittedly with some emotion, to the irony that a person at the very center of a governance crisis in one community would point out the flaws in the governance of a related community.
That said, I have basically no idea what happened AFTER drupalgeddon regarding you personally, other than that I haven't seen you at Drupal events or at the platform.sh booth. I'm not attempting to speak from a position of authority here
@GeePawHill We’re currently voting on an RFC that would add interface default methods (and thus allow multiple inheritance), and I’ve had a few drinks—you might be interested to know this includes rye whiskey.
Add comment