Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130941
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Mon, 18 May 2026 11:33:44 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <439a286b-2944-4cfe-901f-42dd47735ee4@app.fastmail.com>
In-Reply-To: 
 <CALrFCSzoKswiqSb=_fTqDFjGCn4sCjW8X=O4oFzNc+XExOyN0g@mail.gmail.com>
References: 
 <CALrFCSzoKswiqSb=_fTqDFjGCn4sCjW8X=O4oFzNc+XExOyN0g@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][Discussion] Social Media and Marketing Communications
 Policy
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, May 18, 2026, at 10:09 AM, Roman Pronskiy wrote:
> Hi internals,
>
> I'd like to start a discussion on an RFC proposing a formal policy for
> PHP's official social media presence and marketing communications.
>
> RFC: https://wiki.php.net/rfc/social-media-policy
> Policy PR: https://github.com/php/policies/pull/32
>
> The proposal addresses three gaps in current practice:
>
> 1. Custodianship of credentials for official accounts is not formally
> defined, with no documented succession procedures.
>
> 2. There is no documented process for content decisions on official
> channels =E2=80=94 what gets posted, by whom, and under what authority.
>
> 3. There is no framework for deciding which platforms PHP should
> maintain presence on, leading to platform-by-platform ad-hoc
> decisions.
>
> The policy text itself lives in the php/policies repo (PR linked
> above). The wiki RFC is a wrapper proposing its adoption. Inline
> comments on specific policy text are welcome on the PR.
>
> The proposal reflects feedback already received on the previous draft.
> Further feedback is welcome.
>
> -Roman

For the record, I do support greater clarity and process around this top=
ic, so I welcome this RFC.  However, I do have concerns with it in its p=
resent form:

As I noted in a comment (before realizing I should likely post here inst=
ead): Saying "not political" is a trap.  In the current environment, not=
 being political is simply  not an option, because so many things have b=
ecome politicized.  Simply whose name we mention can be political, for r=
easons noted in the comment there.

Similarly, the presented guidelines make no allowance for values-based s=
election of target platforms.  While it would be lovely to say that we'r=
e neutral, the platforms aren't.  I reiterate my previous question: Woul=
d you (general you) be OK with PHP having an account on Truth Social?  O=
r on the Daily Caller forums?  Or 8chan? =20

To be blunt, if your answer to that is "yes" then I don't want you in my=
 project.  Any claim of "neutrality" needs to be moderated to allow avoi=
ding platforms whose values directly contradict ours.  The exact line fo=
r that can be somewhat squishy and contextual, but that allowance MUST b=
e in there.

Regarding membership, there's 2 issues:

1. The social media team is completely self-regulating.  That means it o=
perates without accountability.  At bare minimum there needs to be some =
way for the project as a whole to kick someone out, whether by RFC or so=
me other mechanism.  (Eg, if catturd2 tried to join, I certainly hope mo=
st of us would be opposed to that.)

2. The infrastructure team is completely undefined.  Is the Infra team's=
 membership defined and regulated and documented elsewhere at present?  =
If so, it should be linked.  If not, that's a prerequisite for this poli=
cy doc, because we are giving formal authority to a committee that doesn=
't technically exist.  That's not cool.  Infra having a tighter membersh=
ip policy than Social Media makes total sense; it does not need to opera=
te the same way.  But its operation needs to be defined somehow.

--Larry Garfield