# [RFC] Remove the links to X.com from PHP.net - Thread: https://externals.io/message/130719 - Original archive: https://news-web.php.net/php.internals/130719 - Started by Roman Pronskiy on 2026-04-30T15:55:00+00:00 - Messages: 23 - RFC: Social Media and Marketing Communications Policy (Under discussion) — https://externals.io/rfc/social-media-policy.md - RFC: Remove the links to X.com from PHP.net (Declined) — https://externals.io/rfc/remove-link-to-x-from-php-net.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #130719 — Roman Pronskiy — 2026-04-30T15:55:00+00:00 URL: https://externals.io/message/130719#130719 > https://wiki.php.net/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: 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. 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 --- ## #130720 — Marco Pivetta — 2026-04-30T15:59:29+00:00 URL: https://externals.io/message/130719#130720 · In reply to: #130719 > 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. Leaving Xitter would be appreciated though: some people do in fact give a damn. Marco Pivetta https://mastodon.social/@ocramius https://ocramius.github.io/ --- ## #130723 — Paul M. Jones — 2026-04-30T20:56:08+00:00 URL: https://externals.io/message/130719#130723 · In reply to: #130720 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 --- ## #130726 — Alex \"Pierstoval\" Rock — 2026-05-01T10:27:50+00:00 URL: https://externals.io/message/130719#130726 · In reply to: #130723 > Hi Jim & all, > > Currently, the RFC states: > > > […] > 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"). --- ## #130727 — Alex \"Pierstoval\" Rock — 2026-05-01T10:31:34+00:00 URL: https://externals.io/message/130719#130727 · In reply to: #130719 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. --- ## #130728 — Jorg Sowa — 2026-05-01T10:37:31+00:00 URL: https://externals.io/message/130719#130728 · In reply to: #130726 > 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. --- ## #130729 — Rowan Tommins [IMSoP] — 2026-05-01T11:15:35+00:00 URL: https://externals.io/message/130719#130729 · In reply to: #130719 >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] --- ## #130730 — Andrey Andreev — 2026-05-01T11:56:41+00:00 URL: https://externals.io/message/130719#130730 · In reply to: #130729 Hi, On Fri, May 1, 2026 at 2:18 PM Rowan Tommins [IMSoP] wrote: > > > […] > > > 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. --- ## #130731 — Ilia — 2026-05-01T12:09:23+00:00 URL: https://externals.io/message/130719#130731 · In reply to: #130730 > > 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 --- ## #130732 — Paul M. Jones — 2026-05-01T12:42:16+00:00 URL: https://externals.io/message/130719#130732 · In reply to: #130726 Hi all, > > > > […] > > 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 --- ## #130733 — Rowan Tommins [IMSoP] — 2026-05-01T13:28:53+00:00 URL: https://externals.io/message/130719#130733 · In reply to: #130730 >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] --- ## #130734 — Yitzchok Willroth — 2026-05-01T13:35:01+00:00 URL: https://externals.io/message/130719#130734 · In reply to: #130733 On Fri, May 1, 2026, 9:32 AM Rowan Tommins [IMSoP] wrote: > > > […] > > 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. --- ## #130736 — Chase Peeler — 2026-05-01T15:05:16+00:00 URL: https://externals.io/message/130719#130736 · In reply to: #130732 > Hi all, > > > […] > wrote: > > […] > project to have a presence there > > […] > 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? > > […] > 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 > I agree with Paul. -- Chase Peeler chasepeeler@gmail.com https://linktr.ee/chasepeeler --- ## #130738 — Jim Winstead — 2026-05-01T18:54:37+00:00 URL: https://externals.io/message/130719#130738 > > […] > > 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 --- ## #130739 — Jim Winstead — 2026-05-01T19:10:33+00:00 URL: https://externals.io/message/130719#130739 · In reply to: #130719 > 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 --- ## #130744 — Larry Garfield — 2026-05-02T15:54:37+00:00 URL: https://externals.io/message/130719#130744 · In reply to: #130739 > > > […] > > 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. > > > […] > > 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 --- ## #130745 — Andreas Heigl — 2026-05-02T16:18:07+00:00 URL: https://externals.io/message/130719#130745 · In reply to: #130744 Hey Larry, hey all. > > > […] > > 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 | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +---------------------------------------------------------------------+ --- ## #130747 — Jakub Zelenka — 2026-05-02T19:39:38+00:00 URL: https://externals.io/message/130719#130747 · In reply to: #130745 Hi, > Hey Larry, hey all. > > > > […] > 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. > > […] > 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 --- ## #130748 — Andreas Heigl — 2026-05-02T20:16:16+00:00 URL: https://externals.io/message/130719#130748 · In reply to: #130747 Hey Jakub, Hey All > Hi, > > > > > […] > > 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]: https://github.com/php/web-php/pull/1879 -- ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +---------------------------------------------------------------------+ --- ## #130791 — Gina P. Banyard — 2026-05-07T12:07:03+00:00 URL: https://externals.io/message/130719#130791 · In reply to: #130719 > > > […] > > 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: > > 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. > > 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 project were decided by the project. Thus, the X account is not held "hostage", as its custodianship was transferred 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 have words that follow the announcement. Regards, Gina P. Banyard --- ## #130901 — Jim Winstead — 2026-05-15T20:36:38+00:00 URL: https://externals.io/message/130719#130901 · In reply to: #130738 I intend to open the voting on this RFC on Monday, May 18th (probably around mid-day Pacific time). Thanks. Jim --- ## #130904 — Paul M. Jones — 2026-05-15T23:18:11+00:00 URL: https://externals.io/message/130719#130904 · In reply to: #130901 Hi all, > > > I intend to open the voting on this RFC on Monday, May 18th (probably around mid-day Pacific time). I for one applaud the brave and principled stand codified by the RFC as-written. It takes great courage to announce by implication that the voters-in-favor neither need nor desire the approval, participation, or monetary support of persons and organizations remaining on X (and therefore supporting of or complicit in "white supremacy" and "transphobia"). -- pmj --- ## #130935 — Roman Pronskiy — 2026-05-18T11:05:23+00:00 URL: https://externals.io/message/130719#130935 · In reply to: #130791 > This draft RFC is purposefully misleading. > None of the account created on any social media platform to represent the project were decided by the project. > Thus, the X account is not held "hostage", as its custodianship was transferred 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 have words that follow the announcement. The framing in the RFC reflects how the situation looks from outside the credential circle. If there are facts that change that picture, particularly about custodianship history, the chain of agreement around stopping posting, or anything else you see as cherry-picked, I'd genuinely like to know what they are. The RFC will be revised and I'd prefer it to be accurate. On unilateral action vs. multiple contributors agreeing. There's a distinction between a decision made by one person (which then others agree with) and a decision made transparently. If posting stopped because one custodian decided to stop, and others have since expressed support for that outcome (while many expressed disagreement btw), that's the first case. The governance gap isn't whether the resulting state is popular – it's that the decision-making process wasn't visible or accountable to the project. Per Jakub's point in the parallel thread, I'm going to restructure this as a policy-repo-first proposal rather than a standalone RFC. That changes the appropriate scope significantly. The policy framework and any specific platform decisions become separate documents. -Roman