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
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
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
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").
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.
Hi all,
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
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 thereThis 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
I agree with Paul.
--
Chase Peeler
chasepeeler@gmail.com
https://linktr.ee/chasepeeler
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.
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:
-
Agree how official PHP social media accounts should be governed, and who should have access.
-
Based on that policy, demand access to the X account called "php_official" be transferred.
-
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]
Hi,
On Fri, May 1, 2026 at 2:18 PM Rowan Tommins [IMSoP] imsop.php@rwec.co.uk
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:
Agree how official PHP social media accounts should be governed, and
who should have access.Based on that policy, demand access to the X account called
"php_official" be transferred.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.
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
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]
On Fri, May 1, 2026, 9:32 AM Rowan Tommins [IMSoP] imsop.php@rwec.co.uk
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.
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/changesIt 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'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/changesIt 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
Hey Larry, hey all.
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/changesIt 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 |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+
Hi,
Hey Larry, hey all.
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/changesIt 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
Hey Jakub, Hey All
Hi,
Hey Larry, hey all.
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/changesIt 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 question1 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
--
,,,
(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 |
+---------------------------------------------------------------------+
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/changesIt 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
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