Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:130747 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 58C6D1A00BC for ; Sat, 2 May 2026 19:39:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1777750801; bh=DmzpixJNvPOmPS7tPALkJYEiDKw3aqShUxhgB8lqrtg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=FsBzd8Wm7LB1IpQrWqwO5wfkZaK0yxzMX/Lml3SH9hn/8B1Qusgr22ICNOGglipjH VH08ftZtmgvyP8f+QoPuiKAz6cuO41xc10Dk/W35xTCGYfXjsVY0EBXoYhvkiKD2os VbN2e+Gf2wuK5vJL0s7c9FkiJS0bftW3sqh+DQ5S8JvfbyQq8nAQcUGdAIKzPcZbFF EmPyM5eo7OsAwHKoxXIOP7Q3rZ5zc8VkfJ9lMEZt66Yd5alkWLvF9YwIb1wTCPZxC5 LtxfRQRYv2J7Dqyg2F8GZSAQ7tchI9aPaR5M13v9j+rbE88qgSjq2g80CDKu2zZ4Q5 Y7YLrB+r7QWKQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id DFDED180062 for ; Sat, 2 May 2026 19:39:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: * X-Spam-Status: No, score=2.0 required=5.0 tests=BAYES_50,DMARC_NONE, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 2 May 2026 19:39:55 +0000 (UTC) Received: by mail-oi1-f175.google.com with SMTP id 5614622812f47-466ec4c6846so881138b6e.3 for ; Sat, 02 May 2026 12:39:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1777750790; cv=none; d=google.com; s=arc-20240605; b=VTH8ulPlsfEZMS24JY484XBoNNrNvQ3ytB6TjwG7ToTU8HkR7Llz5OgpFweGaxH7Ci 1V+RXXbocyrOKzuxlY5xsQuuGXCmVOhSlAg0JxcrWSTkqxqOP0cPnjkSGs8k9r8NrZHB 1tT+CZQc9uKI1WM/G9fXCVg4hg+p7g8UB0eN9ORzS+8N3VYU4sIMB+X83Db2jyAoX95a 2CAQ40hUBF1TwRFkiu2uuujDU1GehPVBpGNv/5yE9bVCoWPzXMNwGVxI0S5PMgaBRQMk GiVURMTZ8sT1cIjh2Z4bTAtydDduuEH19F/3cGSs46eYIsj9UGAND+fp2Sj7UruR0Lqr WUAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version; bh=z/F1UFmWvZyHFL08PWDtMszXf14R1l32UffEkHYNF2g=; fh=d3ye5YrNDi/rEceC4MmhwWKhDNg4mekPayGn8iC//cI=; b=iavXfN+MVezkhdrOkIi7B5XcEf/L9Ug2vLspw3r3sTncrKwJf8a0/aQ4FjMTWQxB+k KmVulQnVCdfahQ+HJL97d8NkHng+n0PamiC4tzbwh5VnE/HX8DcW1kk43vmF7M8/m2i+ soxENOXA1Cj+FBD7Ga5sB+LvTpeB4WUWK/Zz8tGIX5zysgBGKIEUbdqS82/J4ZDfX/Ep 1NHX3NwvqxLpEmtmZQGwGRY6iIq/Fk8Gid8V6NLAjWya8uWe/Sj+E2tJMOPGiIESZEDJ FgX0WIlUNZz4jTgLsHG/CMsnKMWkAWjVxcnwGs7Gto/SKkMhwfT0xnoRrCczQqpRhA1I kLJQ==; darn=lists.php.net ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777750790; x=1778355590; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=z/F1UFmWvZyHFL08PWDtMszXf14R1l32UffEkHYNF2g=; b=s6T6RvxRv8zUahgiwqv9EFK3WdpJYVTvKAEmAiiy7PhYrNzYp9dCF/A4cFGeBi//CW 4N1EIHPg63ZiVZASfognNxF54ByQilDAlvG7es6CTNMxUfBcpFQSQeALpPjBW4wCeqaP 8yjNQ8qN/5UV9AR+MyVAAq7L3fqAAU5L1TMvL9kufwh/dSxK1fo3HPsGmZmHzVjIOcXI VifShjohzlwggtJ2IjwwG/bQbCrfEbjgimBn48IZDCeDOcbv8CM3yvmVJx4d9MAkt2bP TlL0LBC54kATw6875bOjB1pfYO4vqoM3IiUClXoS732/NiAHEWhEEceehvq8ujAhX0Xx zgjg== X-Gm-Message-State: AOJu0YzAA0jOBoPAx6Y2mhfWDtbtoiK2EvXOCUkWNHkOPgYvW17ANGzb 6R04LeKNOZMu/foEa/rb1FLRxm3W/9+Rx47Fr/UGMiMQE9i0GeFhUyZeaJ6CF6G2VFBS2Ns/2LI iZpmgDYrGiV5soDGh++KrO0tUcZ0GN/NzXQ== X-Gm-Gg: AeBDieu3vpdZWheWCmrTYM+CE4ic6XT7eQGcY+qLOyxQpNy4suOsJjxhQAoxMHn5zc4 CnEauFFytkhH7BSPgvEhub9w6/x7M1iiqmz9HnerlSrWPiBgJZpo3zrQ40k+qkbZGG0W+9Z7Emx xIG0APgct5d+5WYBUwc2z+ypcaf3b/X5QPTFsJwjqgulwYaOCqkRrpnkAgLN3jsLphS002Ru0hH 7DhqdS49Yow2xGccnj3DpNyakF96HcraFH3Qhf1/yL19S9HmfmuobzfHHwU2pZlhXBzokcDNEd6 dNBUdyFzpRlcOqYsVQ== X-Received: by 2002:a05:6808:e3dc:b0:479:dc28:b71f with SMTP id 5614622812f47-47c892d6a1bmr1516073b6e.40.1777750789894; Sat, 02 May 2026 12:39:49 -0700 (PDT) Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: <5b4527cb-0565-493a-b3fc-dbb981296572@app.fastmail.com> In-Reply-To: Date: Sat, 2 May 2026 21:39:38 +0200 X-Gm-Features: AVHnY4KWX3WW-4QQ5gpnwjEU8RugOarPAxZ1jfI_n_iKiKrDIDXjxVUOvkFnTok Message-ID: Subject: Re: [PHP-DEV] Re: [RFC] Remove the links to X.com from PHP.net To: Andreas Heigl Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="00000000000054b71d0650dadc74" From: bukka@php.net (Jakub Zelenka) --00000000000054b71d0650dadc74 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, On Sat 2. 5. 2026 at 18:20, Andreas Heigl wrote: > Hey Larry, hey all. > > On 02.05.26 17:54, Larry Garfield wrote: > > On Fri, May 1, 2026, at 2:10 PM, Jim Winstead wrote: > >> On Thu, Apr 30, 2026, at 8:55 AM, Roman Pronskiy wrote: > >>> I've drafted an alternative RFC that addresses this directly: > >>> > >>> https://wiki.php.net/rfc/social-media-policy > >>> https://github.com/pronskiy/php-rfc-social-media-policy/pull/1/change= s > >>> > >>> It establishes Infrastructure Team custody of credentials (with > >>> succession procedures, so this situation does not recur) and > >>> Foundation content authority for official channels. Decisions about > >>> which platforms PHP maintains become content decisions within a > >>> documented process =E2=80=94 including the X question, future platfor= ms, and > >>> any reversal of those decisions later. > >> > >> This doesn't do anything to establish the membership and accountabilit= y > >> of either this "Infrastructure Team", and the "temporary > >> administration" of The PHP Foundation itself has continued to fail to > >> deliver on its nearly five-year-old promise to establish governance > >> procedures of its own, and it appears to be content to continue > >> operating that way indefinitely, so I don't believe it is in the > >> interest of the PHP project to wait for that. > >> > >>> I'd ask that this RFC be deferred until the governance framework is i= n > >>> place. Removing a link is trivial to do afterwards, should that be th= e > >>> decision. > >> > >> Respectfully, no. The governance framework we have now is the RFC > >> process, and even if you want to characterize this as ratifying a > >> decision that was made unilaterally by someone, doing that by RFC is > >> the process we have. > >> > >> Cheers. > >> > >> Jim > > > > I fully agree with Jim here. I am 100% in favor of improving our > governance processes, which are currently largely non-existent. I will > happily support those efforts, but they're so haphazard right now that we > need to start at ground 0 first; defining the infra team, how one is adde= d > to it, how one is removed from it, etc. That's a not-small task; one I'm > happy to assist in, but it's a months long process knowing PHP. > > > > Meanwhile, the current process, broken as it is, does have a mechanism > to approve "don't link to this thing," and it's called an RFC. We work > with the process we have, not the process we wish we had. And the proces= s > we have is exactly this thread/RFC, as-is. > > Sorry to disagree here. > > The current process to add or remove things from the PHP website is not > RFC but Nike-based: Just do it. > > And "don't link to this thing on the website because it is outdated and > nothing new is coming" should be a no-brainer. We had other things > removed that were much less outdated. > As soon as there is an objection (which was the case in that PR). RFC is the only mechanism that we have to resolve such disagreement. So it=E2=80= =99s correctly used for the website link part. > The question whether we want to have a presence and whether we want to > try to get that specific presence back online is a different question > and yes! I am with you there: That is something for an RFC. Regardles > whether that is Mastodon, Instagram, X, Facebook, LinkedIn or any other > commercial "social media". > This is actually matter for policy RFC IMO so it should be completely removed from this RFC unless there is a policy update PR. I don=E2=80=99t t= hink it will have any long term impact otherwise because we follow only processes defined in the policy repo. It was too messy to try to collect it from all those process rfc so we decided for that repo for exactly that reason. This also applies to Roman=E2=80=99s RFC. It should be policy repo first ap= proach. Kind regards, Jakub --00000000000054b71d0650dadc74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

On Sat 2. 5. 2026 at 18:20,= Andreas Heigl <andreas@heigl.org> wrote:
Hey Larry, hey all.
On 02.05.26 17:54, Larry Garfield wrote:
> On Fri, May 1, 2026, at 2:10 PM, Jim Winstead wrote:
>> On Thu, Apr 30, 2026, at 8:55 AM, Roman Pronskiy wrote:
>>> I've drafted an alternative RFC that addresses this direct= ly:
>>>
>>> https://wiki.php.net/rfc/social-media-pol= icy
>>> https://github.co= m/pronskiy/php-rfc-social-media-policy/pull/1/changes
>>>
>>> It establishes Infrastructure Team custody of credentials (wit= h
>>> succession procedures, so this situation does not recur) and >>> Foundation content authority for official channels. Decisions = about
>>> which platforms PHP maintains become content decisions within = a
>>> documented process =E2=80=94 including the X question, future = platforms, and
>>> any reversal of those decisions later.
>>
>> This doesn't do anything to establish the membership and accou= ntability
>> of either this "Infrastructure Team", and the "temp= orary
>> administration" of The PHP Foundation itself has continued to= fail to
>> deliver on its nearly five-year-old promise to establish governanc= e
>> procedures of its own, and it appears to be content to continue >> operating that way indefinitely, so I don't believe it is in t= he
>> interest of the PHP project to wait for that.
>>
>>> I'd ask that this RFC be deferred until the governance fra= mework is in
>>> place. Removing a link is trivial to do afterwards, should tha= t be the
>>> decision.
>>
>> Respectfully, no. The governance framework we have now is the RFC<= br> >> process, and even if you want to characterize this as ratifying a<= br> >> decision that was made unilaterally by someone, doing that by RFC = is
>> the process we have.
>>
>> Cheers.
>>
>> Jim
>
> I fully agree with Jim here.=C2=A0 I am 100% in favor of improving our= governance processes, which are currently largely non-existent.=C2=A0 I wi= ll happily support those efforts, but they're so haphazard right now th= at we need to start at ground 0 first; defining the infra team, how one is = added to it, how one is removed from it, etc.=C2=A0 That's a not-small = task; one I'm happy to assist in, but it's a months long process kn= owing PHP.
>
> Meanwhile, the current process, broken as it is, does have a mechanism= to approve "don't link to this thing," and it's called a= n RFC.=C2=A0 We work with the process we have, not the process we wish we h= ad.=C2=A0 And the process we have is exactly this thread/RFC, as-is.

Sorry to disagree here.

The current process to add or remove things from the PHP website is not RFC but Nike-based: Just do it.

And "don't link to this thing on the website because it is outdate= d and
nothing new is coming" should be a no-brainer. We had other things removed that were much less outdated.

As soon as there= is an objection (which was the case in that PR). RFC is the only mechanism= that we have to resolve such disagreement. So it=E2=80=99s correctly used = for the website link part.



The question whether we want to have a presence and whether we want to
try to get that specific presence back online is a different question
and yes! I am with you there: That is something for an RFC. Regardles
whether that is Mastodon, Instagram, X, Facebook, LinkedIn or any other commercial "social media".

This is actually matter for policy RFC IMO so it should be completely= removed from this RFC unless there is a policy update PR. I don=E2=80=99t = think it will have any long term impact otherwise because we follow only pr= ocesses defined in the policy repo. It was too messy to try to collect it f= rom all those process rfc so we decided for that repo for exactly that reas= on.

This also applies to= Roman=E2=80=99s RFC. It should be policy repo first approach.

Kind regards,

Jakub
--00000000000054b71d0650dadc74--