Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130942
Precedence: list
MIME-Version: 1.0
References: <CALrFCSzoKswiqSb=_fTqDFjGCn4sCjW8X=O4oFzNc+XExOyN0g@mail.gmail.com>
 <439a286b-2944-4cfe-901f-42dd47735ee4@app.fastmail.com>
In-Reply-To: <439a286b-2944-4cfe-901f-42dd47735ee4@app.fastmail.com>
Date: Mon, 18 May 2026 12:45:24 -0400
Message-ID: <CALkpNnShdc2rWz0cosLAyAgEvSdBV4f-O2wa6DXNTFdkP8E1tw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][Discussion] Social Media and Marketing
 Communications Policy
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a97f2106521a4a5c"
From: ilia@ilia.ws (Ilia)

--000000000000a97f2106521a4a5c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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.

On Mon, May 18, 2026 at 12:37=E2=80=AFPM Larry Garfield <larry@garfieldtech=
.com>
wrote:

> 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
> 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'r=
e
> neutral, the platforms aren't.  I reiterate my previous question: Would y=
ou
> (general you) be OK with PHP having an account on Truth Social?  Or on th=
e
> 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 avoidi=
ng
> platforms whose values directly contradict ours.  The exact line for that
> can be somewhat squishy and contextual, but that allowance MUST be in the=
re.
>
> 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 som=
e
> other mechanism.  (Eg, if catturd2 tried to join, I certainly hope most o=
f
> 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 t=
he
> same way.  But its operation needs to be defined somehow.
>
> --Larry Garfield
>


--=20
Ilia Alshanetsky
Technologist, CTO, Entrepreneur
E: ilia@ilia.ws
T: @iliaa
B: http://ilia.ws

--000000000000a97f2106521a4a5c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">First, I think the RFC is a great idea, thanks Roman.,<div=
><br></div><div>2nd, social media for the PHP project, IMHO, should focus o=
n advocacy of PHP and serve as a communication tool with the broader user b=
ase about meaningful topics (ie. new releases). As such within=C2=A0reason =
broadest relevant=C2=A0social media presence=C2=A0makes sense.=C2=A0 Exclud=
ing platforms based on personal views, rather than their practical utility =
for addressing the former doesn&#39;t seem logical to me.</div><div><br></d=
iv><div>Lastly, rather=C2=A0than being a manual process, whatever social me=
dia (if any) are decided=C2=A0upon probably should be managed via tooling (=
ie automated posts when a new version is released) instead of relying on an=
y single individual or small group to ensure continuity.</div></div><br><di=
v class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gma=
il_attr">On Mon, May 18, 2026 at 12:37=E2=80=AFPM Larry Garfield &lt;<a hre=
f=3D"mailto:larry@garfieldtech.com">larry@garfieldtech.com</a>&gt; wrote:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, May 18, 2=
026, at 10:09 AM, Roman Pronskiy wrote:<br>
&gt; Hi internals,<br>
&gt;<br>
&gt; I&#39;d like to start a discussion on an RFC proposing a formal policy=
 for<br>
&gt; PHP&#39;s official social media presence and marketing communications.=
<br>
&gt;<br>
&gt; RFC: <a href=3D"https://wiki.php.net/rfc/social-media-policy" rel=3D"n=
oreferrer" target=3D"_blank">https://wiki.php.net/rfc/social-media-policy</=
a><br>
&gt; Policy PR: <a href=3D"https://github.com/php/policies/pull/32" rel=3D"=
noreferrer" target=3D"_blank">https://github.com/php/policies/pull/32</a><b=
r>
&gt;<br>
&gt; The proposal addresses three gaps in current practice:<br>
&gt;<br>
&gt; 1. Custodianship of credentials for official accounts is not formally<=
br>
&gt; defined, with no documented succession procedures.<br>
&gt;<br>
&gt; 2. There is no documented process for content decisions on official<br=
>
&gt; channels =E2=80=94 what gets posted, by whom, and under what authority=
.<br>
&gt;<br>
&gt; 3. There is no framework for deciding which platforms PHP should<br>
&gt; maintain presence on, leading to platform-by-platform ad-hoc<br>
&gt; decisions.<br>
&gt;<br>
&gt; The policy text itself lives in the php/policies repo (PR linked<br>
&gt; above). The wiki RFC is a wrapper proposing its adoption. Inline<br>
&gt; comments on specific policy text are welcome on the PR.<br>
&gt;<br>
&gt; The proposal reflects feedback already received on the previous draft.=
<br>
&gt; Further feedback is welcome.<br>
&gt;<br>
&gt; -Roman<br>
<br>
For the record, I do support greater clarity and process around this topic,=
 so I welcome this RFC.=C2=A0 However, I do have concerns with it in its pr=
esent form:<br>
<br>
As I noted in a comment (before realizing I should likely post here instead=
): Saying &quot;not political&quot; is a trap.=C2=A0 In the current environ=
ment, not being political is simply=C2=A0 not an option, because so many th=
ings have become politicized.=C2=A0 Simply whose name we mention can be pol=
itical, for reasons noted in the comment there.<br>
<br>
Similarly, the presented guidelines make no allowance for values-based sele=
ction of target platforms.=C2=A0 While it would be lovely to say that we=
9;re neutral, the platforms aren&#39;t.=C2=A0 I reiterate my previous quest=
ion: Would you (general you) be OK with PHP having an account on Truth Soci=
al?=C2=A0 Or on the Daily Caller forums?=C2=A0 Or 8chan?=C2=A0 <br>
<br>
To be blunt, if your answer to that is &quot;yes&quot; then I don&#39;t wan=
t you in my project.=C2=A0 Any claim of &quot;neutrality&quot; needs to be =
moderated to allow avoiding platforms whose values directly contradict ours=
.=C2=A0 The exact line for that can be somewhat squishy and contextual, but=
 that allowance MUST be in there.<br>
<br>
Regarding membership, there&#39;s 2 issues:<br>
<br>
1. The social media team is completely self-regulating.=C2=A0 That means it=
 operates without accountability.=C2=A0 At bare minimum there needs to be s=
ome way for the project as a whole to kick someone out, whether by RFC or s=
ome other mechanism.=C2=A0 (Eg, if catturd2 tried to join, I certainly hope=
 most of us would be opposed to that.)<br>
<br>
2. The infrastructure team is completely undefined.=C2=A0 Is the Infra team=
&#39;s membership defined and regulated and documented elsewhere at present=
?=C2=A0 If so, it should be linked.=C2=A0 If not, that&#39;s a prerequisite=
 for this policy doc, because we are giving formal authority to a committee=
 that doesn&#39;t technically exist.=C2=A0 That&#39;s not cool.=C2=A0 Infra=
 having a tighter membership policy than Social Media makes total sense; it=
 does not need to operate the same way.=C2=A0 But its operation needs to be=
 defined somehow.<br>
<br>
--Larry Garfield<br>
</blockquote></div><div><br clear=3D"all"></div><div><br></div><span class=
=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s=
ignature"><div dir=3D"ltr">Ilia Alshanetsky<div>Technologist, CTO, Entrepre=
neur</div><div>E: <a href=3D"mailto:ilia@ilia.ws" target=3D"_blank">ilia@il=
ia.ws</a></div><div>T: @iliaa=C2=A0</div><div>B: <a href=3D"http://ilia.ws"=
 target=3D"_blank">http://ilia.ws</a></div></div></div>

--000000000000a97f2106521a4a5c--