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 RegardsThe voting ended with 10 yes votes and 21 no votes. It means that the RFC has 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 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 |
+---------------------------------------------------------------------+
OpenPGP_signature
Description: OpenPGP digital signature
