On Fri, May 12, 2023, at 3:12 PM, Andreas Heigl wrote: >> For those who voted no, I would kindly ask: What is your alternative? >> >> We have an organizational/structural problem. This isn't really debatable. >> An eager new contributor was just bullied out of contributing, and the one >> process we have for dealing with it (RFCs) failed miserably to handle the >> situation. >> >> Ignoring the problem is a bad option. If the TC proposal isn't your >> preferred way to address it, OK, what is? "Do nothing, it's OK if people >> occasionally get bullied out of contributing" is not an answer. > > The internals list has not only recently "failed" miserably. That is not > to say that it has been like that since time immemoriable and should > therefore stay like that. On the contrary. > > But we already have a group that has "the say" in PHP. The PHP Group is > mentioned in each and every source-file as they are the licence-holder. > > Instead of adding another group I would rather see that existing group > to be filled with new life.
That's an interesting idea. However, the PHP Group consists, AFAIK, of a half dozen people, none of whom are still active in PHP in any meaningful way. Or maybe one. Its legal status is... I don't even know, honestly. Is it an actual registered organization? Or is it just "we say we're the PHP Group so we are" (like most OSS groups)? That said, I'm not sure if the legal side of PHP (which is important, no doubt) should be the same as the technical side of PHP. Those are separate concerns. > Whether that is the right group to tell people in the internals list off > is IMO questionable. Which is also not quite the topic at hand. "People were mean" isn't the problem the TC proposal was trying to solve. "There is no mechanism to resolve purely technical issues that doesn't involve people being mean" is the issue being addressed. When there is a structure vacuum, it gets filled by the loudest and most brash voice that has the least regard for decorum. That's just the nature of humans. Rather than try to fix the loudest and most brash voice, the intent is to fix the structure vacuum. > In essence to me the internals list is a group that discusses technical > topics regarding PHPs sources. The outcome and the vote whether > something will become part of the code is then voted on in an RFC. That > is a rather democratic process. When people are not able to convince the > majority of the voters that their idea is a good idea for the PHP > sources then it might not be a good idea. Having a group of people with > elevated privileges in that process is against that long lived and > established current process. And it looks like internals is not yet at > that point. Again, not the topic at hand. The TC proposal did not change the feature approval RFC process, at all. It was very explicit about that. It was about non-feature decisions that are highly technical. Those simply do not make sense to apply casual direct democracy to. To take the recent example, there's probably only about 10 people who have any meaningful input to give on "should this include statement be here or over here." The other 990 or so RFC voters, quite honestly, do not have anything meaningful or useful to say, and most probably don't even understand the question. And I include myself in that category. On decisions like that, *please do not ask me, I have nothing useful to contribute*. But the selection of those limited people to deal with matters that are, quite frankly, over the head of and below the radar of 99% of us, was proposed to be democratic. It was basically the same process as Release Manager selection. > So for me there already is an elevated group that has a bit more to say > regarding the PHP-sources as they are the once "owning" the licence. > Adding a second group with elevated privileges regarding code-decissions > will not help in keeping the mailinglist civilised and welcoming. Again, separate issues needing separate discussions. (I'm not getting into the CoC topic right now. My skin isn't *that* thick.) We're specifically talking about the "technical matters mediators", to avoid revert-fights like we just had. Keep the topic narrow. > On a sidenote: I'd rather try to find a new solution for the PHP Group > as licence holder. So the idea of having an elected comitee that coupd > perhaps replace the PHP Group was tempting! The license holder needs to be a legal entity, so the TC isn't really that. Whether the PHP Group should be redesigned to be a legal entity is a separate matter that bears discussion, but isn't the topic at hand. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
