Hi, On Sat 2. 5. 2026 at 18:20, Andreas Heigl <[email protected]> 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
