Of all the things I wish Github had, a mailing list service would be really amazing, and the kind of thing that wouldn't be done in the first few months. Sourceforge offers atrocious mailman-based email, larger foss projects on github suffer :(
If it's reporting issues, discussion solutions, and reviewing patches, there are Issues and Pull Requests.
If it's for general discussions about the "future of the project" or bigger-picture topics, I'd use Discourse. It's a really nice way to organize discussions that are one step removed from code-related issues.
If it's for things where you need quick or real time feedback, there's IRC, Gitter, and Slack, all great options for messaging/chat.
Isn't this a bit like saying: if it's for issue tracking, there's Bugzilla/trac/issuetracker/phabric, or if you need a wiki there's moinmon/mediawiki, or if you need a blog there's ghost/wordpress ?
More to the point: IRC (out-of-the-box) doesn't do archiving/search. Slack isn't self-host (which isn't an issue with people using github -- but it does introduce another vendor). Using external services forces you to maintain group membership, user-meta-data either in different user-databases, or via some form of federation.
No longer is removing a user/ssh-key from a github project enough to plug a hole in case of a hacked account.
Discourse isn't (that) bad -- but mailinglists are a lot better IMNHO. If you have a half-decent email program, like mutt, or even (al)pine.
At any rate, the ability to work via email (get bugs via email, close bugs via email) leverage what email is good at: off-line+synchronization. Which is one of the things git is good for. You know, distributed work.
Not sure about authorization and group membership, channel authorization etc -- I assume you'll need to manage slack authorization with slack, and github authorization on the github side.
> If it's for general discussions about the "future of the project" or bigger-picture topics, I'd use Discourse. It's a really nice way to organize discussions that are one step removed from code-related issues.
This is what is appealing and Github offering a builtin-to-github solution for it, with linking to Github accounts, autoformatting etc (like in issues) and so on. There is so much potential.
That's an interesting idea (one of my big blockers for migrating my projects off SourceForge is what to do with the mailing lists).
The issue UI is a little forum-like but is pretty clunky, and, of course, doesn't interact with email very well. Plus you need people to manually tag each issue with 'discussion'.
Are there any UI tweaks that could simplify this? For example, a way to provide a 'new issue' link with default labels?
(Also, is there a good way to import data as issues? I have a tonne of mbox archives that need to go somewhere.)
No, the blocker is setting up mailing lists with a forum-like interface (cf. discourse), but integrated to github (uses the github account) and without actually having to do the setup. Also, without polluting issues.
Actually opening issues via email would be nice to. Trac isn't perfect, but I remember email2trac[1] quite fondly. Combined with email notifications on change, it made it easy to forward bug/error-reports to a trac instance, and automatically create an issue. Or just let support@ go straight to trac.
I still think having an email interface (as in: in addition to a REST API) is very useful. Having a web interface as well isn't bad either.
