Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130791
Date: Thu, 07 May 2026 12:07:03 +0000
To: Roman Pronskiy <roman@pronskiy.com>
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: [RFC] Remove the links to X.com from PHP.net
Message-ID: <IHkbngORyUsc7XJ8ckfEMUHVeXZbtdshQIDiRHaqxtpdyx6Gm8YosRPimZjaqkhBF210q4V-h6PB99oTkMx8xW2k2Tx-bnmReEKgc99GwOw=@gpb.moe>
In-Reply-To: <CALrFCSwr=aK649H2Om2=Vcrfz642JsiNBfCgDVY8U1Z27KDcNg@mail.gmail.com>
References: <CALrFCSwr=aK649H2Om2=Vcrfz642JsiNBfCgDVY8U1Z27KDcNg@mail.gmail.com>
Feedback-ID: 96993444:user:proton
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")



On Thursday, 30 April 2026 at 16:58, Roman Pronskiy <roman@pronskiy.com> wr=
ote:

> On Sun, 12 Apr 2026 16:24:48 +0000, Jim Winstead wrote:
> > https://wiki.php.net/rfc/remove-link-to-x-from-php-net
>=20
> The RFC describes the account as dormant and implies the project has
> chosen not to post on X. Neither is accurate as stated.
>=20
> The account is silent because one credential holder unilaterally
> stopped posting and has not transferred or shared access despite
> repeated requests. That is a governance failure, not a project
> decision. Removing the link in this context does not reflect a project
> consensus to abandon the platform =E2=80=94 it ratifies the outcome of on=
e
> person's unilateral action.
>=20
> That precedent matters beyond X: it establishes that any credential
> holder for any project asset can force a project-wide outcome by
> simply becoming non-responsive. The link will be removed, the account
> will be marked as no longer official, and the underlying procedural
> failure gets retroactively legitimized as a "decision".
>=20
> Larry mentioned earlier in this thread that PHP has never had formal
> procedures for defining "official" accounts. The correct response to
> that observation is to establish those procedures, not to treat their
> absence as license for any individual outcome that happened to result.
>=20
> The link itself represents a project-level commitment that one person
> should not be able to unilaterally undo through inaction. Until the
> credentials question is resolved through a defined process, removing
> the link records the wrong outcome and embeds the wrong precedent.
>=20
> I've drafted an alternative RFC that addresses this directly:
>=20
> https://wiki.php.net/rfc/social-media-policy
> https://github.com/pronskiy/php-rfc-social-media-policy/pull/1/changes
>=20
> 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 platforms, =
and
> any reversal of those decisions later.
>=20
> 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.

This draft RFC is purposefully misleading.
None of the account created on any social media platform to represent the p=
roject were decided by the project.
Thus, the X account is not held "hostage", as its custodianship was transfe=
rred to the current person by the previous person.
Nor is it a unilateral decision, as multiple active core contributor agree =
with this decision.

Moreover, I take issues with quite a few other parts of the draft RFC that =
are once again misleading or false due to cherry-picking examples.
If this draft RFC is published as such in the future, I will definitely hav=
e words that follow the announcement.


Regards,

Gina P. Banyard