Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107216
MIME-Version: 1.0
References: <CA+kxMuTzACohxJcjs43f8xsJPGSMKtDygxje0r2QPmrhFiiRiQ@mail.gmail.com>
In-Reply-To: <CA+kxMuTzACohxJcjs43f8xsJPGSMKtDygxje0r2QPmrhFiiRiQ@mail.gmail.com>
Date: Wed, 18 Sep 2019 13:54:08 -0400
Message-ID: <CAPKYkKyWjq19-m2s8A6veN1_RB-uHi+Nsw07KCp8V9A-6g67UA@mail.gmail.com>
To: Dan Ackroyd <Danack@basereality.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ba46a30592d78654"
Subject: Re: [PHP-DEV] Improving productivity of internals mailing list
From: chasepeeler@gmail.com (Chase Peeler)

--000000000000ba46a30592d78654
Content-Type: text/plain; charset="UTF-8"

On Wed, Sep 18, 2019 at 1:33 PM Dan Ackroyd <Danack@basereality.com> wrote:

> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepeeler@gmail.com

--000000000000ba46a30592d78654--