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

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