[PHP-DEV] Re: [RFC] Remove the links to X.com from PHP.net

Mailing Lists php.internals
1

On Sun, 12 Apr 2026 16:24:48 +0000, Jim Winstead wrote:

PHP: rfc:remove-link-to-x-from-php-net

The RFC describes the account as dormant and implies the project has
chosen not to post on X. Neither is accurate as stated.

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 — it ratifies the outcome of one
person's unilateral action.

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".

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.

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.

I've drafted an alternative RFC that addresses this directly:

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 — including the X question, future platforms, and
any reversal of those decisions later.

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.

-Roman

2

Leaving Xitter would be appreciated though: some people do in fact give a damn.

···

Marco Pivetta

https://mastodon.social/@ocramius

https://ocramius.github.io/

3

Hi Jim & all,

Currently, the RFC states:

due to to the current nature of the site, there is no reason for the project to have a presence there

This is unclear -- what exactly about "the current nature of the site" leads to there being "no reason for the project to have a presence there" ? Can you articulate the specifics, for the record, in the PR?

-- pmj

4

Hi Jim & all,

Currently, the RFC states:

due to to the current nature of the site, there is no reason for the project to have a presence there

This is unclear -- what exactly about "the current nature of the site" leads to there being "no reason for the project to have a presence there" ? Can you articulate the specifics, for the record, in the PR?

-- pmj

Do you really need more details about why X/Twitter is a problem per se? This subject has already been covered in several threads: its owner is a fascist that promotes and enhances fascism with the help of his networks, he deliberately updated the recommendation algorithm to create a personality-cult for his fame, the AI that's bound to this network is p*do-promoting, most of the people that are still there are either fascism-enthusiasts or compliant with what the platform has become (therefore, okay with the statu quo, which means "collaborating with the in-place system").

5

Since PHP is community-driven, maybe instead it could be interesting to create a global PHP-community-wide poll, aside of the "php people with voting rights", to gather more sentiment on whether there should be a "social media policy", or at least to know whether PHP as an "organized community with a lead account" (somehow) should be present on X, or on certain other platforms.

That would help some people like me and others to definitely show whether we are a niche amount of people agreeing on the fact that PHP should leave X, or if there are actual people who care about the image of the language being active on a fascist platform.

6

Do you really need more details about why X/Twitter is a problem per se?

Quote from How To Create an RFC page (https://wiki.php.net/rfc/howto):

Listen to the feedback, and try to answer/resolve all questions. Update your RFC to document all the issues and discussions. Cover both the positive and negative arguments.

7

On 30 April 2026 16:55:00 BST, Roman Pronskiy <roman@pronskiy.com> wrote:

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 — it ratifies the outcome of one
person's unilateral action.

I agree with Roman here: even if there was unanimous agreement that the X account should be shut down, we would need to proceed in stages:

1) Agree how official PHP social media accounts should be governed, and who should have access.

2) Based on that policy, demand access to the X account called "php_official" be transferred.

3) Based on that process, decide whether the X account should be shut down, and if so, what that should look like (e.g. complete account deletion, or profile update to link to other active channels).

Otherwise, we're just setting ourselves up for more problems in future: people creating "official" accounts on other services, then abandoning them, or worse.

Regards,

Rowan Tommins
[IMSoP]

8

Hi,

On Fri, May 1, 2026 at 2:18 PM Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote:

On 30 April 2026 16:55:00 BST, Roman Pronskiy <roman@pronskiy.com> wrote:

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 — it ratifies the outcome of one
person’s unilateral action.

I agree with Roman here: even if there was unanimous agreement that the X account should be shut down, we would need to proceed in stages:

  1. Agree how official PHP social media accounts should be governed, and who should have access.

  2. Based on that policy, demand access to the X account called “php_official” be transferred.

  3. Based on that process, decide whether the X account should be shut down, and if so, what that should look like (e.g. complete account deletion, or profile update to link to other active channels).

Otherwise, we’re just setting ourselves up for more problems in future: people creating “official” accounts on other services, then abandoning them, or worse.

I’m all for addressing the long-term governance issue, and I don’t think anyone else has objected to that.

However, I don’t understand why unlinking this X account from php.net should wait for all of the bureaucracy to play out first. The account has been inactive (or at least hasn’t posted anything) for over a decade it seems, and is currently a liability. To me it’s a no-brainer to remove the link now, and only add it back if/when the situation is resolved.

Cheers,
Andrey.

9

I’m all for addressing the long-term governance issue, and I don’t think anyone else has objected to that.

However, I don’t understand why unlinking this X account from php.net should wait for all of the bureaucracy to play out first. The account has been inactive (or at least hasn’t posted anything) for over a decade it seems, and is currently a liability. To me it’s a no-brainer to remove the link now, and only add it back if/when the situation is resolved.

Agreed, let’s remove stale/dead account and then separately formulate a social media policy (platforms, ownership, responsibility). I think some “political messaging” was added to the original RFC, which caused the confusion.

···

Ilia Alshanetsky
Technologist, CTO, Entrepreneur
E: ilia@ilia.ws
T: @iliaa
B: http://ilia.ws

10

Hi all,

On May 1, 2026, at 05:27, Alex Pierstoval Rock <pierstoval@gmail.com> wrote:

Hi Jim & all,

Currently, the RFC states:

due to to the current nature of the site, there is no reason for the project to have a presence there

This is unclear -- what exactly about "the current nature of the site" leads to there being "no reason for the project to have a presence there" ? Can you articulate the specifics, for the record, in the PR?

-- pmj

Do you really need more details about why X/Twitter is a problem per se? This subject has already been covered in several threads: its owner is a fascist that promotes and enhances fascism with the help of his networks, he deliberately updated the recommendation algorithm to create a personality-cult for his fame, the AI that's bound to this network is p*do-promoting, most of the people that are still there are either fascism-enthusiasts or compliant with what the platform has become (therefore, okay with the statu quo, which means "collaborating with the in-place system").

Great -- if those are the beliefs of the RFC author, they should go directly in the RFC as supporting language for the reasoning behind the RFC.

Then there's a record of exactly who is voting in agreement with those statements, and who is not.

If there is some worry or concern about adding the reasons, that itself will be quite telling.

-- pmj

11

On 1 May 2026 12:56:41 BST, Andrey Andreev <narf@devilix.net> wrote:

However, I don't understand why unlinking this X account from php.net
should wait for all of the bureaucracy to play out first.

For one thing, removing the link doesn't actually solve the problem. The account is still there for people to find, marked "official", under the control of someone who disputes the right of the project to control it.

If nobody was offering to tackle the problem, it would be a stop-gap, but Roman *is* offering to tackle it.

I'm not *against* removing the link, if it's otherwise unanimous, but it seems wasteful to have two parallel debates on the same topic.

Rowan Tommins
[IMSoP]

12

On Fri, May 1, 2026, 9:32 AM Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote:

On 1 May 2026 12:56:41 BST, Andrey Andreev <narf@devilix.net> wrote:

However, I don’t understand why unlinking this X account from php.net
should wait for all of the bureaucracy to play out first.

For one thing, removing the link doesn’t actually solve the problem. The account is still there for people to find, marked “official”, under the control of someone who disputes the right of the project to control it.

If nobody was offering to tackle the problem, it would be a stop-gap, but Roman is offering to tackle it.

I’m not against removing the link, if it’s otherwise unanimous, but it seems wasteful to have two parallel debates on the same topic.

Rowan Tommins
[IMSoP]

If I read between the lines correctly, the person who currently controls the account doesn’t dispute the right of the project to control it, rather the right of the project sans a method of governance to control it.

If that’s an accurate read, the RFC to establish governance, should it be approved, would solve both issues.

13

I agree with Paul.

···

Chase Peeler
chasepeeler@gmail.com
https://linktr.ee/chasepeeler

14

On Fri, May 1, 2026, at 5:40 AM, Paul Jones wrote:

On May 1, 2026, at 05:27, Alex Pierstoval Rock <pierstoval@gmail.com> wrote:

Hi Jim & all,

Currently, the RFC states:

due to to the current nature of the site, there is no reason for the project to have a presence there

This is unclear -- what exactly about "the current nature of the site" leads to there being "no reason for the project to have a presence there" ? Can you articulate the specifics, for the record, in the PR?

-- pmj

Do you really need more details about why X/Twitter is a problem per se? This subject has already been covered in several threads: its owner is a fascist that promotes and enhances fascism with the help of his networks, he deliberately updated the recommendation algorithm to create a personality-cult for his fame, the AI that's bound to this network is p*do-promoting, most of the people that are still there are either fascism-enthusiasts or compliant with what the platform has become (therefore, okay with the statu quo, which means "collaborating with the in-place system").

Great -- if those are the beliefs of the RFC author, they should go
directly in the RFC as supporting language for the reasoning behind the
RFC.

Then there's a record of exactly who is voting in agreement with those
statements, and who is not.

If there is some worry or concern about adding the reasons, that itself
will be quite telling.

I don't think I have been coy about the reasons at all, but I have updated the RFC. I'll consider this a major change, so voting will happen after the 14-day cooling period. (So I will send another message about the intent to call the vote in about a week.)

Cheers.

Jim

15

On Thu, Apr 30, 2026, at 8:55 AM, Roman Pronskiy wrote:

I've drafted an alternative RFC that addresses this directly:

PHP: rfc:social-media-policy
Add Social Media Policy RFC text by pronskiy · Pull Request #1 · pronskiy/php-rfc-social-media-policy · GitHub

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 — including the X question, future platforms, and
any reversal of those decisions later.

This doesn't do anything to establish the membership and accountability 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 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 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

16

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:

PHP: rfc:social-media-policy
Add Social Media Policy RFC text by pronskiy · Pull Request #1 · pronskiy/php-rfc-social-media-policy · GitHub

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 — including the X question, future platforms, and
any reversal of those decisions later.

This doesn't do anything to establish the membership and accountability
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 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
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 added 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 process we have is exactly this thread/RFC, as-is.

--Larry Garfield

17

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:

PHP: rfc:social-media-policy
Add Social Media Policy RFC text by pronskiy · Pull Request #1 · pronskiy/php-rfc-social-media-policy · GitHub

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 — including the X question, future platforms, and
any reversal of those decisions later.

This doesn't do anything to establish the membership and accountability
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 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
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 added 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 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 outdated and nothing new is coming" should be a no-brainer. We had other things removed that were much less outdated.

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".

And re-adding the link then should then not be much of an issue at all.

Right now though the link is sending people to an outdated profile implying that PHP is outdated and nothing new came for the last few years...

Cheers

Andreas

--
                                                               ,
                                                              (o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| Appointments - Nextcloud |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+

18

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 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 — including the X question, future platforms, and
any reversal of those decisions later.

This doesn’t do anything to establish the membership and accountability
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 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
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 added 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 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 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’s 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’t think 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’s RFC. It should be policy repo first approach.

Kind regards,

Jakub

19

Hey Jakub, Hey All

On 02.05.26 21:39, Jakub Zelenka wrote:

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 directly:

PHP: rfc:social-media-policy
Add Social Media Policy RFC text by pronskiy · Pull Request #1 · pronskiy/php-rfc-social-media-policy · GitHub

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 — including the X question, future platforms, and
any reversal of those decisions later.

This doesn't do anything to establish the membership and accountability
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 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
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 added
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 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 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’s
correctly used for the website link part.

Again I'd like to disagree.

The "objection" on the PR in question[1] was not whether we should remove the link to to an account that has been inactive for several years on X but whether we should have a presence on X (for whoever "we" is. Personal note: Certainly not me)

No single comment on that PR objected to the removal of the link.

In that PR I have several times tried to keep the topics separate.

One is: Shall PHP have a presence on X
Second is: Shall the PHP presence on X be actively managed
Third is: Shall we **right now** link to a presence on X that is no longer actively maintained (for whatever reason) and that gives the impression PHP has stopped doing anything since the release of PHP8.3 on the 23rd of November 2023.

The PR only targets the third topic!

I find it hilarious that we can not decide upon **right now** removing a link to a currently not active presence on the internet!

Removing this link is not as if it is set in stone! Once we get the presence back online we can at any time re-add the link.

The PR does **not** target topics one and two! Whether we need an RFC for those or whatever else is totally not what I am concerned about! Let's deal with those separately from the PR!

But let'S get to the point where we can decide upon **right now** removing a link to a resource that SCREAMS "410 Gone"

And when that resource is back again, let's hope that readding the link doesn't need to be signed in triplicate, sent in, sent back, queried, lost, found, subjected to public inquiry, lost again, and finally buried in soft peat for three months and recycled as firelighters.

My 0.02 €

Cheers

Andreas

[1]: Remove X/Twitter link from homepage social media section by castillo-n · Pull Request #1879 · php/web-php · GitHub

--
                                                               ,
                                                              (o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| Appointments - Nextcloud |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+