Everything

php

Home » Project » Newsgroups » php.internals » Re: [RFC] Remove the links to X.com from PHP.net »

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

php.internals

Roman Pronskiy

124 days ago

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

> 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

Marco Pivetta

124 days ago

On Thu, 30 Apr 2026 at 17:55, Roman Pronskiy <roman@pronskiy.com> wrote:

> 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/

Paul M. Jones

123 days ago

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

Alex Pierstoval Rock

123 days ago

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

Joerg Sowa

123 days ago

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

Paul M. Jones

123 days ago

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

Chase Peeler

123 days ago

On Fri, May 1, 2026 at 8:45 AM Paul M. Jones <pmjones@pmjones.io> wrote:

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

I agree with Paul.

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

Alex Pierstoval Rock

123 days ago

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.

Rowan Tommins [IMSoP]

123 days ago

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]

Andrey Andreev

123 days ago

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.

Ilia Alshanetsky

123 days ago

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

Rowan Tommins [IMSoP]

123 days ago

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]

Yitzchok Willroth

123 days ago

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.

Jim Winstead

122 days ago

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

Larry Garfield

122 days ago

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.

--Larry Garfield

Andreas Heigl

122 days ago

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.

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                          |
+---------------------------------------------------------------------+

Jakub Zelenka

121 days ago

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

Andreas Heigl

121 days ago

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

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                          |
+---------------------------------------------------------------------+

Gina P. Banyard

117 days ago

On Thursday, 30 April 2026 at 16:58, Roman Pronskiy <roman@pronskiy.com> wrote:

> On Sun, 12 Apr 2026 16:24:48 +0000, Jim Winstead wrote:
> > 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.

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

Roman Pronskiy

106 days ago

On Thu, May 7, 2026 at 2:07 PM Gina P. Banyard <internals@gpb.moe> wrote:

> 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