Future-proofing discussion platform

[lidel]

I know that there are more pressing issues in the project: I am writing this just as a suggestion for years to come, not something that requires immediate attention :-)

Right now IPFS community does just fine with Google Groups, but I feel it may not be enough when community (and general interest in project) gets bigger.

Main issues to anticipate with Google Groups in future:

• Web interface is not a first-class citizen (let's be honest, it is still the email-first solution), which may scare non-technical people off from asking questions or simply browsing old conversations and learning in the process. IRC channel (and its web logs) is actually more user-friendly to join and participate right now, which says it all ;-)
• Lack of categories and tags results in a mixed bag of discussions, which in turn makes filtering and participation really hard
• Google stopped improving Groups for some time already, which is a bad sign: history had shown they may decide to kill it at some point (just like they did with Reader, Wave, and a long list of other services). So migration from Groups may be forced anyway, I guess it may be better to do it sooner than later.

It may be a good idea to solve these problems before it impacts community's communication and productivity.

---

Possible solution: replace Google Group with self-hosted Discourse instance
(eg. https://discuss.ipfs.io).

Discourse is an open source Internet forum software that empowers communities by giving them state of the art discussion platform. It is fast, reliable, and used by big names such as Docker, Ubuntu or even Twitter.

A quick overview of features can be found at:
http://www.discourse.org and http://www.discourse.org/about/

Please check it out before reading further.

I'll just hint at some features that may be especially useful for us:

Multiple login options

Users can register and login with Github, Google, Facebook, Twitter or a regular login and password.
The friction and hassle is minimal. The only requirement is a working email.

Code Syntax Highlighting

I feel this would make discussions around code much easier.
Discourse uses https://highlightjs.org which supports various languages (including Go) and configuration file formats. Support for specific languages can be enabled/disabled by admin.

Oneboxing

What is Oneboxing? http://try.discourse.org/t/what-is-a-onebox/276

Links to most of Github resources are whitelisted by default and oneboxed quite nicely.
Even the line highlights are supported (example).

Mailing list mode and responses via email

Users can choose what kinds of notifications are sent to them via email (watching/tracking topics, @mentions, etc).
It is also possible for a user to enable mailling-list mode in which every new post is sent via email (same a Google Groups).
They can respond via email too (same as for Github's issue notifications).

This gives a great flexibility and should make both web-native and email-native folks happy.

Try it

There is a special sandbox instance where you can safely create disposable posts:
http://try.discourse.org

Installation and Maintenance

Discourse is a dockerized application (user data is kept outside of docker image), so as long as you can run docker you can install it.
This is a good place to start. Generally these generic steps are enough to have it up and running.

Backups are automatic (good practice is to set up copying daily .tar.gz to other machine).
Updates can be performed via ssh (cd /var/discourse/ && git pull && ./launcher rebuild app) or web gui at /admin/upgrade.

I am maintaining internal instance at work and it is really easy to run once it is set up.
If IPFS project chooses to use Discourse, I'd be glad to help with initial setup and configuration.

IPFS Ideas for Discourse itself

I think that at some point IPFS could be used as a storage backend for mirrored images and post attachments or even encrypted backups and Discourse could provide hints to browsers about IPFS URIs (ipfs/ipfs-companion#16).

We could also create onebox solutions for IPFS URIs which could be included upstream to improve IPFS interop across all discussion communities.

[jbenet]

Hey @lidel

Right now IPFS community does just fine with Google Groups, but I feel it may not be enough when community (and general interest in project) gets bigger.

Mailing lists scale fine. take go-nuts, the linux kernel, git, ... as interests emerge, mailing lists are split.

But I also don't particularly like mailing lists. I much prefer github issues.

Discourse

Sorry, I hate discourse. I tried hard to like it but it's just way too complicated and unintuitive. It's a polarizing product.

---

@lidel is there anything that github issues isn't doing for you? They function very much like mailing lists and discourse forums, they're much easier to use, and happen to be linked to all our code / project issues / identities.

I think that many of the conversations that happen on IRC now should move to github issues on one of the repos (potentially this one, or https://github.com/ipfs/faq). We'll consider pointing people to one of these repos instead of the mailing list -- the only reason it's there is several people asked me for it because they refuse to use anything but email.

[lidel]

is there anything that github issues isn't doing for you? They function very much like mailing lists and discourse forums, they're much easier to use, and happen to be linked to all our code / project issues.

If Discourse is out of the picture, I see your point. Github is indeed simple and probably “good enough”.

I was not thinking about Github in terms of a general discussion for some reason.. maybe because just like a single mailing list it does not provide structure for it (no categories, and tags can be assigned only by staff). In my mind it mostly accommodates developer workflow (Open → Discuss → Implement → Close). But I guess one can keep issues open indefinitely and/or use multiple repos, just like you suggested.

I think the gist of this discussion is to explicitly point people to preferably one place for now (eg.https://github.com/ipfs/faq).
If someone wants to participate, can simply Watch the repo and it will work like a bit better mailing list with a much nicer web interface:

[jbenet]

and tags can be assigned only by staff

i'd be fine adding everyone who is interested in assigning tags to be collabs on the repo (sort of mods).

I think the gist of this discussion is to explicitly point people to preferably one place for now (eg. https://github.com/ipfs/faq). If someone wants to participate, can simply Watch the repo and it will work like a bit better mailing list with a much nicer web interface:

Yeah, watching the repo is encouraged.

the FAQ does not cover "help me with this random problem". do you think we should also have something like https://github.com/ipfs/troubleshooting or https://github.com/ipfs/help ? or maybe just use this (the community repo) for that too? (I think so far we're very responsive and haven't seen anyone complain about not having their questions addressed, -- maybe we're doing ok and adding things is premature)

[lidel]

I think current state is quite fine: the ipfs/community feels more 'meta', so questions/support and a general discussion fall into ipfs/faq.

You may want to think about renaming the faq repo to something broader (help, support, discussion, talk), but to be honest I don't feel strongly about it either way.

Simply making sure it stands out on the http://ipfs.io/docs/ page (currently not even there) should be enough. :-)

[jbenet]

Simply making sure it stands out on the http://ipfs.io/docs/ page (currently not even there) should be enough. :-)

👍 ipfs-inactive/website#12

[RichardLitt]

I think this should be closed, given the work done above.