Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107214
MIME-Version: 1.0
Date: Wed, 18 Sep 2019 18:33:19 +0100
Message-ID: <CA+kxMuTzACohxJcjs43f8xsJPGSMKtDygxje0r2QPmrhFiiRiQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Improving productivity of internals mailing list
From: Danack@basereality.com (Dan Ackroyd)

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.

# 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