Everything

php

Home » Project » Newsgroups » php.internals » Improving productivity of internals mailing list »

Improving productivity of internals mailing list

php.internals

Dan Ackroyd

6 years ago

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

Chase Peeler

6 years ago

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

Dan Ackroyd

6 years ago

On Wed, 18 Sep 2019 at 18:33, Dan Ackroyd <Danack@basereality.com> wrote:

>
> 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

On Wed, 18 Sep 2019 at 18:54, Chase Peeler <chasepeeler@gmail.com> wrote:

> On Wed, 18 Sep 2019 at 18:33, Dan Ackroyd <Danack@basereality.com> wrote:

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

cheers
Dan
Ack

Bishop Bettini

6 years ago

On Wed, Sep 18, 2019 at 1:33 PM Dan Ackroyd <Danack@basereality.com> wrote:

>
> ...
>
> # 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.

Zeev Suraski

6 years ago

On Wed, Sep 18, 2019 at 8:33 PM Dan Ackroyd <Danack@basereality.com> wrote:

> # 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.

Olumide Samson

6 years ago

Hi Zeev,

Not trying to be a distraction(I shouldn't even have messaged), but I guess
you might be waking everyone up to some facts these recent days(probably in
the wrong way, and to some; positive).

Why did i write this?

I've been following closely lately and have seen you(Zeev Suraski)
question *RFC
authority*(what it was meant for or not, even though your facts weren't
written as facts anywhere).

You've questioned the *mailing list* rules(be it binding or not), maybe it
should be followed or disregarded and just follow my/your-style rules.

You've questioned the *RFC votes*(majority can never be 2/3 but only
7/1),even thousands of majority votes can never push a deprecation through
to the php-src because you didn't agree to that and possibly there's a veto
somewhere which can be used because you are one of those listed in the PHP
Group.



Is this not mocking PHP internal developers to the outside world when you
could just sit at home and chill or take a coffee when you can?

Like Dan said, some old members are not following the mailing list
rules(what you call moral etiquette), maybe since everything in the PHP
internals has been going without a goal, why not just have the initial
developer(Rasmus ledorf) or a group of people write out one(clear mission,
goal statement, milestones, rules, etc) and stop the easy confusion going
on in this mailing list?


On Wed, Sep 18, 2019, 11:11 PM Zeev Suraski <zeev@php.net> wrote:

Zeev Suraski

6 years ago

On Thu, Sep 19, 2019 at 1:44 AM Olumide Samson <oludonsexy@gmail.com> wrote:

> I've been following closely lately and have seen you(Zeev Suraski)
> question *RFC authority*(what it was meant for or not, even though your
> facts weren't written as facts anywhere).
>

You've questioned the *mailing list* rules(be it binding or not), maybe it

> should be followed or disregarded and just follow my/your-style rules.
>

There's a reason of why you're suddenly seeing those recently, and it's not
me waking up one day deciding to question the authority of the RFC process
or the mailing list rules.  They have to do with new occurrences that me
and some others are *reacting *to.  Applying the RFC process to areas that
until very recently were simply not even up for discussion, let alone a
vote.  Applying mailing list rules and/or the RFC process to shutdown
dissenting voices and threaten them.  This is unprecedented and
unacceptable.

To be clear, I'm not 'questioning' neither the RFC process nor the mailing
list rules.  But they are what they are - documents written by humans (very
flawed ones, at least in the former case) in certain contexts and for
certain purposes (and in a very short time with almost no discussion).
While the RFC process has been used extensively in the last few years with
a good degree of success - it was never meant to be used as an exclusive
way to govern all aspects of the PHP project, and other tenets (which
weren't codified, as they were obvious at the time the RFC process was
introduced) for which we have a de-facto written track record are just as
important (bias for BC, PHP as a lenient and dynamic language, open
discussion, etc.).  The mailing list rules were meant as a first stab at
creating a nicer atmosphere for internals@ - not as a tool to limit
people's ability to respectfully express themselves.  Both are very
useful.  But they did not descend from heaven to rule everything (RFC
process) nor to force everyone into submission (mailing list rules).

Zeev

P.S.: Regarding the 3rd thing you mentioned, the description of my position
was completely off;  If interested, you're very welcome to follow up with
me off list, as I don't want to bug everyone with it.

Rowan Collins

6 years ago

On 18 September 2019 18:33:19 BST, Dan Ackroyd <Danack@basereality.com> wrote:

># 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]

Dan Ackroyd

6 years ago

On Fri, 20 Sep 2019 at 19:52, Rowan Tommins <rowan.collins@gmail.com> wrote:

>
> I think we should be making that volume easy to work with, not trying to reduce it as an end itself.

As I've said elsewhere, I think having a central place for people to
find interesting conversations/things to work on, would help direct
people's energy for making PHP better to productive activities. Hence:
https://github.com/Danack/RfcCodex/blob/master/project_coordination.md

> Although initially resistant, I'm coming around to the idea that
> the mailing list should be replaced with some other kind of forum.

Every time this has been suggested in the past, the idea hasn't been progressed.

If you want to work on that idea, please do so. But in the meantime,
the mailing list is what we have.

cheers
Dan
Ack

Rowan Collins

6 years ago

On 21 September 2019 12:18:20 BST, Dan Ackroyd <Danack@basereality.com> wrote:

>On Fri, 20 Sep 2019 at 19:52, Rowan Tommins <rowan.collins@gmail.com>
>wrote:
>>
>> I think we should be making that volume easy to work with, not trying
>to reduce it as an end itself.
>
>As I've said elsewhere, I think having a central place for people to
>find interesting conversations/things to work on, would help direct
>people's energy for making PHP better to productive activities. Hence:
>https://github.com/Danack/RfcCodex/blob/master/project_coordination.md

This is definitely an interesting idea, but I think it's solving a different problem. A notice board for finding "interesting conversations" across half a dozen different platforms is very different from having a central place where suggestions can be made, feedback given, and ultimately decisions taken.

Right now, the mailing list is officially that central place. If you think it's not the right tool for the job, then we need to discuss what other tools to replace it with. Similarly, if you think there are types of discussion which should be considered off-topic, we should have somewhere to send those, rather than putting them in the same category as abusive messages.

My concern with keeping some things on the list, but sending some elsewhere, is that it's not always easy to move a conversation once it's started. People will either try to carry it on against advice, or simply give up contributing. So if we're discussing moving some things off the list, then I think it makes sense to discuss the option of moving everything instead.

Regards,

--
Rowan Tommins
[IMSoP]