Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107273
Date: Fri, 20 Sep 2019 19:51:56 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <CA+kxMuTzACohxJcjs43f8xsJPGSMKtDygxje0r2QPmrhFiiRiQ@mail.gmail.com>
References: <CA+kxMuTzACohxJcjs43f8xsJPGSMKtDygxje0r2QPmrhFiiRiQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: internals@lists.php.net
Message-ID: <4469175B-5FE6-46E6-8787-E7256C39FB7C@gmail.com>
Subject: Re: [PHP-DEV] Improving productivity of internals mailing list
From: rowan.collins@gmail.com (Rowan Tommins)

On 18 September 2019 18:33:19 BST, Dan Ackroyd <Danack@basereality=2Ecom> w=
rote:
># Problem 2 - Some threads are not a good fit for a mailing list=2E
> =2E=2E=2E
>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=2E
> =2E=2E=2E
>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=2E People who have only recently joined the mailing list,
>probably shouldn't be sending as many emails=2E


I notice that in several of your recent messages, on and off list, you ide=
ntify the *number* of messages to the mailing list as a key problem=2E Whil=
e it's certainly true that this can be quite a high-volume forum, I think w=
e should be making that volume easy to work with, not trying to reduce it a=
s an end itself=2E

One of the points in your proposed etiquette guide is "you don't have to r=
eply to every message"=2E I think there is a corollary, "you don't have to =
read every message"=2E For instance, if a proposal or question leads to a s=
eries of back-and-forth clarifications, those should be visible to anyone i=
nterested, and easily skipped for anyone not=2E However, the current platfo=
rm perhaps makes this more difficult than it should be=2E

Although I'm subscribed using a Gmail account, I access the list mainly th=
rough Thunderbird, display posts in a tree view, and regularly leave indivi=
dual messages and whole sub-threads unread, even if I'm actively participat=
ing in a different branch of the same thread=2E Other clients make this muc=
h harder - GMail's "conversations" are optimised for linear exchanges betwe=
en two or three people, and are frankly awful for working with a mailing li=
st=2E

Although initially resistant, I'm coming around to the idea that the maili=
ng list should be replaced with some other kind of forum=2E 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 in=
to their own top-level thread=2E

Notably, GitHub PRs fail to meet this requirement, as was clear in the rec=
ent experiment=2E Like Gmail, they're built for a very different task=2E

On a final note, there are definitely times when people do send too much t=
o the list, but it's generally not the volume itself that's the problem, bu=
t repetition, lack of clarity, or lack of focus=2E Better support for threa=
ds or topics wouldn't solve those, but it would solve the common case of "t=
his part of the conversation isn't relevant to me but I want to read the re=
st"=2E

Regards,
Hi Dan,
--=20
Rowan Tommins
[IMSoP]