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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
