Hi Internals,

I've been thinking about how "non-productive" our internals mailing
list has been, both for many years, and particularly the last couple
of weeks. I've come to at least one conclusion; using only an email
based mailing list as the main project management tool for a project
the size and scope of PHP is not a great idea.

I think there's a couple of different problems, and so a couple of
different solutions needed.

Problem 1 - It's really hard to see what is being or could be worked on.

People sometimes announce things that they think could be worked on
through the internals list, in the hope that people might want to help
them do that work. Or sometimes just as a hope that someone else would
pickup that work.

That information is really hard to find.

Solution

As an experiment I'm going to attempt to keep a list of items that
could be worked on over at
https://github.com/Danack/RfcCodex/project_coordination.md alongside
the curated summary of discussions of common ideas for RFC that failed
to reach approval.

I'll post a digest of changes to that list each week to internals, so
that people can see the things that could be worked on.

If people have things they would like added to the list, please either
open a PR or an issue. I'll also try to pick up stuff people mention
and ask people individually if they want them added to the list.

Once we can see if that is useful or not, we can think about moving it
to a more permanent location, as well as distributing the workload
keeping a list like that updated.

Problem 2 - Some threads are not a good fit for a mailing list.

For some threads, it is appropriate for people to take time to really
think through the previous message before responding on the list. For
other threads, for example when people are asking for help with
something, it is appropriate for people to reply really quickly.

The quick, conversational exchanges are not a good fit for our email
system.

An example of this can be seen through the experiment Nikic did for a
possible Union Types RFC at https://github.com/php/php-rfcs/pull/1

Out of the 204 comments, there were a few that were not productive
(imo) however the vast majority of them were useful, and the format of
the comments allowed a much better technical analysis of the code.
This is a much better analysis than has happened for pretty much any
other RFC.

Solution

We should move as many conversations off the internals list as we can,
while still retaining ways of people finding where those conversations
are being held. To be clear, I'm not suggesting changing our RFC
process.

The official discussion should (imo) still be announced and carrier
out on the mailing list, but hopefully there would be fewer messages
needed, if the technical discussion has already happened elsewhere.

Problem 3 - Newcomers to the mailing list aren't following our etiquette.

Although we have a general etiquette list that should be covered by
all people in here
(
https://git.php.net/?p=php-src.git;a=blob_plain;f=docs/mailinglist-rules.md;hb=HEAD
), people who are new to the list may need a little more guidance that
doesn't apply to core PHP maintainers.

For example, it's appropriate for people who are release managers to
be sending as many emails as they need to, to manage the release
process. People who have only recently joined the mailing list,
probably shouldn't be sending as many emails.

I've drafted some updated etiquette rules that are more focused on and
easier to understand for people who are new to the mailing list here:
https://wiki.php.net/email_etiquette_for_people_new_to_php_internals

I am interested in having a discussion about whether there are any
other things to be noted, or if any of the ones I wrote could be
phrased better.

I'm OK with this if discussions over proposed RFCs (not just, "what do you
think about an RFC for xyz") is moved to a separate medium. Whether that's
a discussion board, a different mailing list, or something else.

Changes to PHP have as much of an impact to those that are part of the core
team as they do those that are not. Limiting their voice because of that is
dangerous and sends a horrible message to non-core members: "your opinion
doesn't matter as much" - and it doesn't take long before the "as much"
part gets lost in the shuffle. I know that isn't the intention, but, that
will be the result. To be honest, I already get the impression that some
people feel that way towards me.

I also don't think it's fair to expect people to limit the responses they
make to others responses. I'm only aware of one time where I sent two
responses to a single email. In all other instances I have kept it 1:1.
Now, when 5 different people are making points that I feel warrant a
response, that's going to lead to those people sending 1 email each while I
send 5. If it's a minor issue, then I probably won't respond to each one,
maybe not at all. However, if it's an issue which I think is critical, like
the uninitialized variables, I'm going to be thorough in my responses. The
gravity of the topic demands such behavior. That means if person A makes
point A, and I respond, and later person B also makes point A, then I'm
going to respond to them as well, with pretty much the same response -
since they obviously didn't see my first response.

Solution

We should not be too timid to, very nicely, ask people to consider how
their behaviour is affecting how usable the mailing list is for PHP
core developers.

If someone who has not contributed to PHP, ignores that feedback and
makes it difficult for us to have productive conversations on this
mailing list, then that would be a different problem than the
well-intentioned but accidental disruption people who are new to the
group are causing, and so should be handled separately.

Problem 4 - Senior project members aren't following our email etiquette.

Solution: I'll post an RFC to address this.

cheers
Dan
Ack

--

--
Chase Peeler
chasepeeler@gmail.com

As an experiment I'm going to attempt to keep a list of items that
could be worked on over at
https://github.com/Danack/RfcCodex/project_coordination.md

Apologies, the link should have been:
https://github.com/Danack/RfcCodex/blob/master/project_coordination.md

Your response, within 21 minutes, including the time taken to write
the response, is noted.

cheers
Dan
Ack

...

Problem 1 - It's really hard to see what is being or could be worked on.

People sometimes announce things that they think could be worked on
through the internals list, in the hope that people might want to help
them do that work. Or sometimes just as a hope that someone else would
pickup that work.

That information is really hard to find.

Solution

As an experiment I'm going to attempt to keep a list of items that
could be worked on over at
https://github.com/Danack/RfcCodex/project_coordination.md alongside
the curated summary of discussions of common ideas for RFC that failed
to reach approval.

Thanks, Dan. While bugs.php.net is our canonical to do list, it doesn't
have much in the way of planning features. For the phar and imap extension,
I maintain a supplemental list on my whiteboard -- but that's no way to
share the load. I'd like to see bugs.php.net grow to be more of a project
management platform, but for now, I like where you're headed with a simple
list. I've created a PR for the extensions I maintain, and I hope other
maintainers will do the same.

Problem 3 - Newcomers to the mailing list aren't following our

etiquette.

Problem 4 - Senior project members aren't following our email etiquette.

This too isn't directed so much at Dan, but rather the list at large.

Some facts about the Mailing List Rules:

Fact #1: The list rules were never a binding document. It wasn't voted on
or otherwise agreed upon as binding at any point at any point. In fact, I
can't even find any reference that it was even ever discussed (my email
archive dates back to 1999). It was written by Lukas Kahwe Smith, and with
the exception of some whitespace and typo fixes - it's literally in an
"initial commit .. feedback appreciated" stage (
https://github.com/php/php-src/blame/master/docs/mailinglist-rules.md).
Fact #2: It contains three chapters. The first chapter - which includes
the goals of the document - i.e., what the other rules are aimed to
ultimately facilitate - is concluded with "Increase the general level of
good will on planet Earth". <opinion>This rule is clearly violated time and
again by several recent folks and proposals.</opinion>
Fact #3: Chapter 2 contains the rules, i.e., the supposedly binding rules
(see Fact #1). I think they're all healthy and non controversial, and we
should all strive to abide by them. <opinion>That said, interestingly, some
of the folks who most clearly violate the first item on this chapter appear
to eagerly want to enforce this document as binding.</opinion>
Fact #4: Chapter 3 contains "general hints", which are clearly non-binding
even if the document itself was (see Fact #1). Specifically, the first two
items in the 3rd chapter are purposely phrased as suggestions on what to do
as opposed to Thou Shalt or Thou Shalt Not, even if one ignores the
'general hints' label that is applied to this entire section. These items
appear to be repurposed by some here as a way to silence opposition to
extremely controversial proposals. A "you should try to do X" request in a
"general hints" section in a document that was apparently never agreed upon
as binding will not do that, nor will anything else.
Bonus fact: Decision was only achievable through near-consensus back in
the day these rules were written; Substantial opposition wasn't facing the
risk of being ignored and overrun as it does today..

There's another fact about what RFCs can or cannot do, but I think I've
spent enough digital ink on that already.

The recent discussions we've had on this list were not pleasant for anyone.
To say I took no pleasure at the discussions of the last few months would
be a top contender for the understatement of the century. However, from my
POV - I had no choice in the matter - and had to react to discussions that
were imposed on me. The alternative - which I view as betraying countless
users - isn't a real alternative from my point of view. I know for a fact
that many others had similar thoughts (yes, beyond just Chase and Stas) -
but were wary about voicing their opinions when they saw the 'summary
trials' I faced in certain forums, or just didn't have the energy to fight
what appeared to be a sisyphic task against an internals@ majority that
doesn't seem to care.

There are very few folks on internals@ that are actively working to protect
PHP's excellent BC track record, as well as keeping it from severing its
roots. It does mean that they are disproportionately represented in such
discussions. While I would absolutely love there to be others that will
join this effort that is as of late repeatedly imposed on us - we will
continue doing what we have to.

Ultimately, the only way to avoid having these tiresome, waste of time
controversial discussions, is to stop bringing up controversial zero sum
game proposals. If you accidentally bring one up - backtrack, and figure
out a win/win solution or simply abandon it. If you insist on following
through with it - while spending plenty of Good Will credit and forcing
people to defend their positions - expect to have to endure a pretty tough
debate. No mailing list rules or RFCs will change that.

Zeev

P.S.: Intimidating folks by "noting their response time" - when their
response clearly doesn't violate anything about the rules - isn't only
gross, it's a downright regression to 1984. The antithesis for the stated
goals of the document, and knowing Lukas - probably the very exact opposite
to what he had in mind. Nobody should do that.

Problem 2 - Some threads are not a good fit for a mailing list.

...
We should move as many conversations off the internals list as we can,
while still retaining ways of people finding where those conversations
are being held.
...
For example, it's appropriate for people who are release managers to
be sending as many emails as they need to, to manage the release
process. People who have only recently joined the mailing list,
probably shouldn't be sending as many emails.

I notice that in several of your recent messages, on and off list, you identify the number of messages to the mailing list as a key problem. While it's certainly true that this can be quite a high-volume forum, I think we should be making that volume easy to work with, not trying to reduce it as an end itself.

One of the points in your proposed etiquette guide is "you don't have to reply to every message". I think there is a corollary, "you don't have to read every message". For instance, if a proposal or question leads to a series of back-and-forth clarifications, those should be visible to anyone interested, and easily skipped for anyone not. However, the current platform perhaps makes this more difficult than it should be.

Although I'm subscribed using a Gmail account, I access the list mainly through Thunderbird, display posts in a tree view, and regularly leave individual messages and whole sub-threads unread, even if I'm actively participating in a different branch of the same thread. Other clients make this much harder - GMail's "conversations" are optimised for linear exchanges between two or three people, and are frankly awful for working with a mailing list.

Although initially resistant, I'm coming around to the idea that the mailing list should be replaced with some other kind of forum. One of the key features would be good support for branching threads, ideally including the ability to move messages which have drifted away from an original topic into their own top-level thread.

Notably, GitHub PRs fail to meet this requirement, as was clear in the recent experiment. Like Gmail, they're built for a very different task.

On a final note, there are definitely times when people do send too much to the list, but it's generally not the volume itself that's the problem, but repetition, lack of clarity, or lack of focus. Better support for threads or topics wouldn't solve those, but it would solve the common case of "this part of the conversation isn't relevant to me but I want to read the rest".

Regards,
Hi Dan,

Rowan Tommins
[IMSoP]