Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130744
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Sat, 02 May 2026 10:54:37 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <cd40ae92-0f57-47f5-9c4e-fcb1618bdfc8@app.fastmail.com>
In-Reply-To: <5b4527cb-0565-493a-b3fc-dbb981296572@app.fastmail.com>
References: 
 <CALrFCSwr=aK649H2Om2=Vcrfz642JsiNBfCgDVY8U1Z27KDcNg@mail.gmail.com>
 <5b4527cb-0565-493a-b3fc-dbb981296572@app.fastmail.com>
Subject: Re: [PHP-DEV] Re: [RFC] Remove the links to X.com from PHP.net
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

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/changes
>>
>> 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=20
> of either this "Infrastructure Team", and the "temporary=20
> administration" of The PHP Foundation itself has continued to fail to=20
> deliver on its nearly five-year-old promise to establish governance=20
> procedures of its own, and it appears to be content to continue=20
> operating that way indefinitely, so I don't believe it is in the=20
> interest of the PHP project to wait for that.
>
>> I'd ask that this RFC be deferred until the governance framework is in
>> place. Removing a link is trivial to do afterwards, should that be the
>> decision.
>
> Respectfully, no. The governance framework we have now is the RFC=20
> process, and even if you want to characterize this as ratifying a=20
> decision that was made unilaterally by someone, doing that by RFC is=20
> the process we have.
>
> Cheers.
>
> Jim

I fully agree with Jim here.  I am 100% in favor of improving our govern=
ance processes, which are currently largely non-existent.  I will happil=
y 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 added t=
o 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 t=
o approve "don't link to this thing," and it's called an RFC.  We work w=
ith the process we have, not the process we wish we had.  And the proces=
s we have is exactly this thread/RFC, as-is.

--Larry Garfield