Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120244 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 71757 invoked from network); 12 May 2023 15:36:41 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 12 May 2023 15:36:41 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 705D5180506 for ; Fri, 12 May 2023 08:36:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS19151 66.111.4.0/24 X-Spam-Virus: No X-Envelope-From: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 12 May 2023 08:36:39 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6F55E5C01C1 for ; Fri, 12 May 2023 11:36:39 -0400 (EDT) Received: from imap50 ([10.202.2.100]) by compute4.internal (MEProxy); Fri, 12 May 2023 11:36:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= garfieldtech.com; h=cc:content-type:content-type:date:date:from :from:in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1683905799; x= 1683992199; bh=9o6KFQs4x3nVLFcA/ovQvDW98yMCk6kX9mNTGQrZHso=; b=V Ej4E3FhBFzt3mWJv7BjJius0Z2pM+c/9Tu2LiNwh5TA56f9smajUOxEl28Kip0r7 lXYdt4/OSGrxCGk24jj1hGIbKCa+PLaaObdBBCK7yBenVQl07zqLBRR37niKqEqD orHEsiGwlAjuZ0rRVNrE0CVFcGy8BxxTvYkX4xhB6XwCHhBE4opRnXYT1EbJfLri /PnyTx8xoUGbaTAN7gFp76ZeVAkiiy9BCD2/1BJzxi8mw/0Nrdms8b5jSRaF8guq 0jN48xJkP60uDrFEF3Pnh5F/YnsGiTvlCdtL25CqyKuZTi//mg9JED0lcNeDSU/S IaqdF4Qjzg5BPGygMKv6Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1683905799; x=1683992199; bh=9o6KFQs4x3nVL FcA/ovQvDW98yMCk6kX9mNTGQrZHso=; b=laGMy13UtS5gwYB+dRnxNLXolctBX JEvJGBi/lCCNk8K129/leQOCzdHt+HC2tNPKa6ujfUgfz+IKpY1PERRilF0Kh5vW dYFJrIBVnatc/T06yWlOmtu6YriX6N5TYvGG2NdggQN8y5z0r0brO7hj6iQWrUup r1HMJfdbPxb/hBkelXVxcht7fZRRnxxYogq9Dq8slkXNLtJwphCIHM01T+odFQ9f bYJQDohY4r2NNiWli2g+vaFwdSeESYbdKo6lv8l36e/7XDj31WkiYy7PODgGk3wZ HgrGcsqVnucm/AV3WgQufcr03x1uJC1nbr54wzFsTyk8F0+QH+a1VORHw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeehtddgledtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdfnrghr rhihucfirghrfhhivghlugdfuceolhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtoh hmqeenucggtffrrghtthgvrhhnpeeglefgkeduiedvvdetffeujefftdfhjeeiveehgfff keduveektddvledvvdfffeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh X-ME-Proxy: Feedback-ID: i8414410d:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 01A191700089; Fri, 12 May 2023 11:36:38 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-415-gf2b17fe6c3-fm-20230503.001-gf2b17fe6 Mime-Version: 1.0 Message-ID: In-Reply-To: <68bd0906-40ec-9e30-67ad-d4af881eb480@heigl.org> References: <68bd0906-40ec-9e30-67ad-d4af881eb480@heigl.org> Date: Fri, 12 May 2023 15:36:18 +0000 To: "php internals" Content-Type: text/plain Subject: Re: [PHP-DEV] Re: [VOTE] PHP Technical Committee From: larry@garfieldtech.com ("Larry Garfield") 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