On Fri, 12 May 2023 at 18:12, Andreas Heigl <andr...@heigl.org> wrote:
> Hey Larry, Hey all > > On 12.05.23 16:42, Larry Garfield wrote: > > On Fri, May 12, 2023, at 11:57 AM, Jakub Zelenka wrote: > >> On Fri, Apr 28, 2023 at 11:00 AM Jakub Zelenka <bu...@php.net> wrote: > >> > >>> Hi, > >>> > >>> The vote is now open for the RFC about introduction of the PHP > Technical > >>> Committee: > >>> > >>> https://wiki.php.net/rfc/php_technical_committee > >>> > >>> Regards > >>> > >>> > >> The voting ended with 10 yes votes and 21 no votes. It means that the > RFC > >> has been declined. Thanks for voting. > >> > >> Regards > >> > >> Jakub > > > > 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. > > Whether that is the right group to tell people in the internals list off > is IMO questionable. > > 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. > > Having a group of people that make sure that the tone on the list is > civil, on-topic and inviting to newcomers is a different story. But that > was not what the vote was about. > > 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. > > 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! > > So my alternative would be for everyone to every now and then reread > https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md > > And as a second step to make internals more welcoming and inclusive > might be to have people keep an eye on the tone that can intervene when > the debate gets too heated. Those IMO need to be respected people and > their influence is in those matters purely on keeping the tone civilized > and not have a veto right in regards to code. The internals list and in > the end the vote on an RFC should have the last say in regards to code. > > My 0.02€ > > Cheers > > Andreas > > -- > ,,, > (o o) > +---------------------------------------------------------ooO-(_)-Ooo-+ > | Andreas Heigl | > | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | > | https://andreas.heigl.org | > +---------------------------------------------------------------------+ > | https://hei.gl/appointmentwithandreas | > +---------------------------------------------------------------------+ > | GPG-Key: https://hei.gl/keyandreasheiglorg | > +---------------------------------------------------------------------+ > Hello Andreas! I think what Larry is asking are ideas on actual solutions, what steps should be made and working out how those recent situations should have been solved/handled. Really it does not matter if will it be PHP Group or some called something else. There has been a lot of discussion off the list in communities among PHP developers and nobody considers the recent events as something that should have happened. The time to "let's throw around some ideas" has passed. The current situation highly reminds me of the year prior to the introduction of the RFC process: this going down a hill at a rapid pace and a lot of people yelling "la la la la" while plugging their ears. The world has changed, and the new breed of developers has grown up in a very different environment. I personally as a developer am a completely different person and I do not accept what has been a norm 5-10 years ago today. The development world moved on, it changed radically. It's time to be the big boys and accept that what worked past 10-20 years is not acceptable any more and the project has to adapt to the modern times. I already wrote about how ridiculous the decision not to include cleanup is. It's like a "birds against flying" campaign... I've personally have been talking to a few people with core dev access about figuring out a way to introduce some kind of communication and coordination type people to the project, whose role is to filter out "the noise", communicate with the community, put concisely feedback for the technical people so they don't have to be forced to communicate when they don't want to (and I see a lot of RFC's basically being ignored by a majority of the voters then to suddenly speak up after the fact). And those people could help mediate the process - making sure things just don't get abandoned just because everybody flipped over their tables and stormed off. In the modern day, people expect a very different style of communication. And, sadly, those are the people who make decisions like "should we abandon PHP and move to Go or JavaScript" and so on. The other part that irks me a lot how php.net is developed - while it is fine and it works, I have seen people lose all interest as soon as they open the code. Nobody wants to touch it. And nobody wants to be responsible for it too as far as I can tell. The windows build machine.... I really don't have to explain anything here, do I? -- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Telegram: @psihius https://t.me/psihius
