On Friday, April 20, 2018, Donald Stufft email@example.com wrote:
Currently in the packaging space, we have a number of avenues for communication, which are:
Is there something like a collaboration plan with a decision tree / flow chart / list of what types of communications are best communicated on which platform?
GitHub Team Discussions 
The result of this is that all discussion ends up being super fractured amongst the various places. Sometimes that is exactly what you want (for instance, someone who is working on the wheel specs probably doesn’t care about deprecation policy and internal module renaming in pip) and sometimes that ends up being the opposite of what you want (for instance, when you’re describing something that touches PyPI, setuptools, flit, pip, etc all at once).
Theoretically the idea is that distutils-sig is where cross project reaching stuff goes, IRC/gitter is where real time discussion goes, and the various project mailing lists and issue trackers are where the project specific bits go. The problem is that often times doesn’t actually happen in practice except for the largest and most obvious of changes.
"Please refer to the communications flowchart: [url]"
I think our current “communications stack” kind of sucks, and I’d love to figure out a better way for us to handle this that solves the sort of weird “independent but related” set of projects we have here.
Do GitHub project boards help?
Team email and web notifications on GitHub work like this: @pypa/core
From my POV, a list of our major problems are:
A collaboration plan might include this contact information for each team member
IDK how many times we've discussed upgrading mailman to add per message footer links to relayed messages. Google Groups has this feature on by default.
Issues, Pull Requests, Wikis, and Team Discussions are all editable.
I EDITED THIS.
One can unsubscribe from issue notifications
This is a fenced code block in Markdown and GFM: (GitHub Flavored Markdown)
These create a trackback on the mentioned issue:
This sends notifications to each mentioned user according to their GitHub notification settings:
/cc @westurner @dstufft @pypa/core
 https://github.com/sindresorhus/refined-github "Display possibly related issues on the 'New Issue' page" https://github.com/sindresorhus/refined-github/pull/1188
These aren’t new problems, and often times the existing members of a community are the least effected becasue they’ve already spent effort learning the ins and outs and also curating a (typically custom) workflow that they’ve grown accustomed too. The problem with that is that often times that means that new users are left out, and the community gets smaller and smaller as time goes on as people leave and aren’t replaced with new blood, because they’re driven off but the issues with the stack.
Is this in the contributing docs? In CONTRIBUTING.rst 
Are there standard ISSUE_TEMPLATE/name.md and PULL_REQUEST_TEMPLATE/name.md ?  https://github.com/joelparkerhenderson/github_special_files_and_paths
A big part of the place this is coming from, is me sitting back and realizing that I tend to be drawn towards pulling discussions into Github issues rather than onto the varying mailing lists, not because that’s always the most appropriate place for it, but because it’s the least painful place in terms of features and functionality. I figure if I’m doing that, when I already have a significant investment in setting up tooling and being involved here, that others (and particularly new users) are likely feeling the same way.
A bot that watches the [mailing lists,] and adds issue/PR trackbacks might be super useful.
Each service has information access optimizations that people like most. GitHub is designed for software development. These days, I send feature requests to firstname.lastname@example.org with an "ENH: ..." subject line.
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig