The PHP project maintains official accounts on several social media platforms, but it has no formal policy governing those accounts. Credentials are held by individual community members, posting decisions are ad hoc, and there is no defined process for adding, retiring, or recovering accounts.
This RFC proposes adopting a formal Social Media and Marketing Communications Policy. The policy text is provided as a companion pull request to the php/policies repository. Approving this RFC adopts that policy document.
The PHP project currently maintains official accounts on Twitter/X (@official_php), Mastodon (@php@fosstodon.org), and LinkedIn (@phpnet). These accounts operate without a formal governance framework, which has produced concrete problems:
The Twitter/X account illustrates the cost of these gaps in practice. It has approximately 109,000 followers but has been silent since June 4, 2024 — not as a result of a project decision, but because the credential holder ceased posting unilaterally. Multiple requests to share credentials, transfer custody, or enable automated posting (as is already done for Mastodon within the same requests) have not been accommodated, and no formal mechanism exists to resolve the situation.
This RFC does not propose any specific outcome for the Twitter/X account. It proposes a policy under which such outcomes become deliberate, documented, and reversible — rather than the result of inaction or unilateral choices by individual credential holders.
This RFC proposes adopting a formal Social Media and Marketing Communications Policy for the PHP project. The policy text is provided as a companion pull request to the php/policies repository.
The policy establishes:
systems@php.net and the php/infrastructure repository — with a minimum of three (3) holders per account, a public list of credential holders, secure storage, documented succession, and responsibility for automation and technical operations.php/policies, amendable by pull request through an open and transparent process, without requiring an RFC. These operational policies must not conflict with the policy itself.Operational details are defined in the policy document itself, in keeping with the PHP project's practice of locating process definitions in php/policies.
The policy assigns credential custody to the PHP Infrastructure Team and content authority to a new, open-volunteer PHP Social Media Team. This reflects:
An earlier draft of this RFC named the PHP Foundation as the content authority. This was replaced by an open-volunteer Social Media Team because:
If the community prefers a different structure, this RFC can be amended during discussion.
This RFC establishes a new policy and does not affect any existing PHP functionality or code.
Current holders of official PHP social media credentials will be asked to:
No individual's contributions or historical stewardship are diminished by this policy. The intent is to formalize and extend existing practices, not to criticize past volunteers.
The PHP Infrastructure Team. A minimum of three (3) Infrastructure Team members hold credentials for each official account, with documented succession and emergency-access procedures. The credential holders for each account are publicly listed. Social Media Team members do not hold credentials by virtue of that role.
The policy defines it by reference: the existing group of volunteers who maintain the PHP project's infrastructure, coordinated through the systems@php.net mailing list and the php/infrastructure repository. The Infrastructure Team predates this RFC and its membership is not governed here; formalizing infrastructure governance more broadly is out of scope. What this policy does require is transparency where it touches social media: a public list of the credential holders for each official account.
The initial roster will be populated upon adoption, with current credential holders willing to participate as well as additional volunteers from the PHP community. The roster is public and maintained in the policy file.
A prospective member proposes themselves to the existing team. The team agrees on its own internal process for accepting or declining new members. Members should have a demonstrated connection to the PHP community — contributions to php-src, the documentation, the infrastructure, a PHP user group, or comparable involvement. Additions to the roster are announced on the internals mailing list, and the roster pull request stays open for at least a week so the community can comment before it is merged.
Three mechanisms, in increasing order of weight. The team can remove a member through its own internal process. Prospective members can be objected to during the announcement and comment window before they join. And as a backstop, the community can remove a member — or reconstitute the team entirely — through the project's RFC process. The team is self-organizing for day-to-day matters, but it is accountable to the project as a whole.
None by default. The Social Media Team MAY delegate specific responsibilities to the PHP Foundation — for example, drafting marketing campaigns or curating content — but is not structurally required to involve the Foundation. Delegation is recorded publicly and revocable at any time. Delegation never transfers credential custody.
Separately, individual PHP Foundation staff or members MAY volunteer to join the Social Media Team in a personal capacity, subject to the same membership criteria as any other volunteer. In that case they participate as individual team members, not as representatives of the Foundation.
The policy assigns content authority to the Social Media Team and custody to the Infrastructure Team. The Infrastructure Team executes posting on behalf of the Social Media Team for non-automated content; its role is technical execution, not content review. Significant cross-team disputes SHOULD be raised on the internals mailing list.
The authoritative list of official accounts lives in the policy's Scope section and is updated by pull request. The procedure for adding, retiring, or recognizing accounts is defined in the Social Media Team's own operational policies document, not in the RFC-governed policy — the team can refine the procedure without an RFC. The community MAY request an RFC if it considers a particular retirement a project-level decision.
Yes. The policy may be amended by a future RFC with 2/3 majority approval. Updates to the team roster, routine Scope-list changes, and the team's operational policies document do not require an RFC.
The policy separates the two layers. Content is neutral: official communications focus on PHP and take no positions on platform politics or non-PHP commercial matters. Platform presence is discretionary: nothing in the policy obliges the project to establish or maintain a presence on any particular platform. The project decides where it wants to be, and the Social Media Team may decline a platform it considers a poor fit for an official PHP presence — the “reach” principle is a goal, not an obligation.
That discretion is deliberately constrained by process, because the project has already experienced the failure mode unstructured discretion invites: the Twitter/X account went dormant through an individual's unilateral, undocumented decision. Under this policy that cannot recur in either direction. Adding or retiring an account must follow the documented procedures, a retirement must be announced on the internals mailing list before taking effect, and the community can escalate a contested decision to an RFC. Conversely, the no-silent-abandonment principle requires posting (at minimum automated content) to continue on every platform listed in Scope — quietly ceasing activity on a listed platform is itself a policy violation.
Yes. The policy governs only official PHP project accounts. Community members, Foundation staff, and core developers are encouraged to continue personal advocacy for PHP.
A single yes-or-no vote on the policy as a whole, requiring 2/3 majority.
social-media/team-operations.rst) amendable by pull request without an RFC: content categories (automated, curated, marketing) and the procedure for adding and removing official accounts. The policy retains only project-level constraints, including prohibited content.systems@php.net, php/infrastructure) and required a public list of credential holders per account.