Hey Arvids, Hey all On 12.05.23 17:48, Arvids Godjuks wrote:
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 PHPTechnicalCommittee: https://wiki.php.net/rfc/php_technical_committee RegardsThe voting ended with 10 yes votes and 21 no votes. It means that theRFChas been declined. Thanks for voting. Regards JakubFor those who voted no, I would kindly ask: What is your alternative? We have an organizational/structural problem. This isn't reallydebatable. 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 yourpreferred 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?
Larry asked what alternatives those who voted "No" see.My main topic that I seem not to have been able to get across is that to me there is no need to implement alternatives as everything is already there.
* We have rules for the list.* We have a workflow that should prohibit stuff getting into the core from new developers without at least a second set of eyes and in case of strong disagreement a separate discussion * We have an elected group of people that has the say about the part of the source that they are responsible for
That is my personal opinion and the reason why I did vote the way I voted. This is not "throwing around some ideas".If you want to know what my next steps would be (now we are throwing around ideas): Hire someone that makes sure that we are actually observing the rules that are already there?
Which brings us to another point that you mentioned: PHP is solely based on voluntary development. Some core-devs are paid by the community via the PHPFoundation. But in essence that is still based on voluntary work. People volunteer to do stuff and get paid for that.
That is a bit like Python but definitely different to languages like Java, C or even JavaScript.
So getting a stronger organizational background for PHP along with a more structured approach to infrastructure is definitely a good idea. But that is not the question that was asked by Larry.
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 |
+---------------------------------------------------------------------+
OpenPGP_signature
Description: OpenPGP digital signature
