[PHP-DEV] [RFC][Discussion] Social Media and Marketing Communications Policy

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: PHP: rfc:social-media-policy
Policy PR: Social Media and Marketing Communications Policy by pronskiy · Pull Request #32 · php/policies · GitHub

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

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: PHP: rfc:social-media-policy
Policy PR: Social Media and Marketing Communications Policy by pronskiy · Pull Request #32 · php/policies · GitHub

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 — 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 topic, so I welcome this RFC. However, I do have concerns with it in its present form:

As I noted in a comment (before realizing I should likely post here instead): Saying "not political" is a trap. In the current environment, not being political is simply not an option, because so many things have become politicized. Simply whose name we mention can be political, for reasons noted in the comment there.

Similarly, the presented guidelines make no allowance for values-based selection of target platforms. While it would be lovely to say that we're neutral, the platforms aren't. I reiterate my previous question: Would you (general you) be OK with PHP having an account on Truth Social? Or on the Daily Caller forums? Or 8chan?

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 avoiding platforms whose values directly contradict ours. The exact line for that can be somewhat squishy and contextual, but that allowance MUST be in there.

Regarding membership, there's 2 issues:

1. The social media team is completely self-regulating. That means it operates 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 some other mechanism. (Eg, if catturd2 tried to join, I certainly hope most 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 policy doc, because we are giving formal authority to a committee that doesn't technically exist. That's not cool. Infra having a tighter membership policy than Social Media makes total sense; it does not need to operate the same way. But its operation needs to be defined somehow.

--Larry Garfield

First, I think the RFC is a great idea, thanks Roman.,

2nd, social media for the PHP project, IMHO, should focus on advocacy of PHP and serve as a communication tool with the broader user base about meaningful topics (ie. new releases). As such within reason broadest relevant social media presence makes sense. Excluding platforms based on personal views, rather than their practical utility for addressing the former doesn’t seem logical to me.

Lastly, rather than being a manual process, whatever social media (if any) are decided upon probably should be managed via tooling (ie automated posts when a new version is released) instead of relying on any single individual or small group to ensure continuity.

···

Ilia Alshanetsky
Technologist, CTO, Entrepreneur
E: ilia@ilia.ws
T: @iliaa
B: http://ilia.ws

Larry, thanks the feedback, made changes based on all of it. Updated
PR: Social Media and Marketing Communications Policy by pronskiy · Pull Request #32 · php/policies · GitHub

On Mon, May 18, 2026 at 6:37 PM Larry Garfield <larry@garfieldtech.com> wrote:

As I noted in a comment (before realizing I should likely post here instead): Saying "not political" is a trap. In the current environment, not being political is simply not an option, because so many things have become politicized. Simply whose name we mention can be political, for reasons noted in the comment there.

The neutrality wording now only applies to content and the policy
explicitly says applying those rules is up to the social media team.

Similarly, the presented guidelines make no allowance for values-based selection of target platforms. While it would be lovely to say that we're neutral, the platforms aren't. I reiterate my previous question: Would you (general you) be OK with PHP having an account on Truth Social? Or on the Daily Caller forums? Or 8chan?

I didn't add values language but I think the result may be ok with
you. There's now a "discretion" principle. Presence on any platform is
never an obligation and the team can say no to a platform it thinks is
a bad fit.

1. The social media team is completely self-regulating. That means it operates 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 some other mechanism. (Eg, if catturd2 tried to join, I certainly hope most of us would be opposed to that.)

New members get announced on internals and the roster PR stays open a
week so people can object. And the community can always remove someone
(or the whole team) by RFC vote.

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 policy doc, because we are giving formal authority to a committee that doesn't technically exist. That's not cool. Infra having a tighter membership policy than Social Media makes total sense; it does not need to operate the same way. But its operation needs to be defined somehow.

It seems not defined anywhere explicitly, but there is
PHP: systems and
GitHub - php/infrastructure: The Ansible Playbooks to maintain the PHP infrastructure · GitHub. So policy now defines it by
reference, the existing folks on systems@php.net / php/infrastructure
repo, plus credential holders per account have to be listed publicly.
Properly formalizing infra governance is a way bigger job than this
RFC, I don't think it should block it.

-Roman