-
Notifications
You must be signed in to change notification settings - Fork 226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discourse - Better community building #69
Comments
As seen from the logs, I would very much appreciate a forum for discussing IPFS and IPFS related things like IPNS and the technologies around the whole shebang. Also, closing down the number of places we discuss things would be good. There are a number of benefits, biggest ones being easy for newcomers to find information and getting into the community, and better search-ability (lacking another word for this...) |
What would be really cool is a web forum built on IPFS. |
@amstocker yes that would be a great project. But it will be along way to having a forum on the level of discourse and until we have I feel it's important to use existing tools that are working very well for other communities. |
Well looks like I should have used the search first. feels stupid now Ref #15 That being said I still think that there is room for improvement, from my side it doesn't have to be discourse but a proper forum software could help a lot especially for newcomers to the community. |
@dignifiedquire I definitely agree that we need an established web forum, I was just throwing the IPFS forum idea out there :) . Right now in order to keep up I just go into the IRC logs and CTRL+F my username and several other keywords of interest (e.g. python, etc.), then I also browse the monday sprint logs and todo lists and watch a handful of ipfs github repos. Maybe we should make a subreddit like /r/ipfs-dev or something like that? The current one (https://www.reddit.com/r/ipfs) seems to have a decent amount of activity. |
just to point out, we have https://github.com/ipfs/community and https://github.com/ipfs/support If anyone wants to take a more active role in the community, we can make you a collaborator (mod) on either, giving you the ability to tag, edit and close posts. (And change readme stuff) |
@amstocker I am building a Discussion Board platform on top of IPFS. I plan to open source it in the following days, I need to finish the prototype and the documentation. Maybe, when it works well enough (it needs some feature in go-ipfs 0.4 to be completed) it could be used for discussion. EDIT: here's the link to the repo However I think a discourse server, a custom platform or any other solution that requires allocating time away from other more important matters is not a goold solution, even though the discussions are fragmented right now, they still work fine |
It would be really, really rad if we could get a "github issues like" post system on top of ipfs. we're really there. it would also motivate us to fix a lot of things on our end. to make life easy we can run a hosted instance that delegates ipfs ops to our nodes until the js-ipfs node is ready. |
@fazo96 have a link to a working example? what do you need from the gateway to make it work? is writable enough? |
@jbenet there you go: http://ipfs.io/ipfs/Qmbf34Vdo3TtnFugSQQPzGfjjq6SBcgDfBB6P9kmSQs9Ay It should work except when IPNS records expire and no one on the network has them. It should work better on 0.4, but there's no one with actual data for the platform so you can't test it yet. Next think I'll write is ability to publish stuff from the browser (which will only support go-ipfs 0.4 because I need that sweet files api) so that it gets a little more usable. Everything I need to make it work is already in go-ipfs 0.4 Of course, when js-ipfs hits our browsers, you won't even need a local go-ipfs instance Here's the repo if you want to take a look at how it works: https://github.com/fazo96/ipfs-boards EDIT: my platform is like a discussion board, it has almost all the features you would need for replacing the github issues, so when it's done (or at least ready) it could be used :) |
Don't feel stupid! We should have dealt with that issue. You're 100% on point and awesome for bringing this up. @fazo96, that looks awesome.
I agree with this. I think that ipfs/community and ipfs/support meet our needs at the moment, and that a lot of issues can be dealt with by better signposting. I've been going through and working on those (see PRs above), and will continue to think about how our community looks to a newcomer. But a forum would be great! I just don't want to add another standard lest we XKCD the whole shebang. (I didn't even know there was a subreddit for IPFS). |
Relevant:
|
cc @mekarpeles @davidar as they're interested in this too. |
i chatted with @dignifiedquire about this a while back, and I expressed my strong resistance to discourse.org. My reservations in general are:
Now, my personal opinion on discourse itself:
However...However, I do recognize the value and need for general forums where people can discuss and propose anything. (something like a subreddit or a general forum). Free form discussion is very valuable to communities. So I do recognize the need for something like discourse. My ProposalThere's people working on building towards forum solutions on ipfs itself:
I say that we channel the energy and desire for a forum into building our own board on top of ipfs itself. We're not far, and this will make us achieve three very important goals:
Obviously achieving parity with github issues or discourse is very, very hard. but i'm willing to bet that if we have something very simple that works, totally open source, distributed, and hackable, it will promote an explosion of communication UIs on top of a core communication datastructure. |
+1 for common denominator message formats like "POST". I see this as the parallel to WebDAV. Over this, it could be very practical to support other formats like Calendar functionality (CalDAV), todo lists & issues,
Also a great way to isolate "practical" usability issues that the [developer] community will likely care about and face as they write apps (like @haadcode's which I thought was great).
It has some nice features (just as slack does), and they have the potential to be helpful (in their own regards) -- but the biggest feature of a communication service (as @jbenet suggests) is that all relevant data can't be navigated from within the same stream. Otherwise (what we have today) is like driving an automobile and having your speedometer on your phone and your fuel level sensor on a radio station. You can use some of these services in parallel, and context switch between others quickly, but if there's not continuity between your data sources, there's no filter mechanism or policy, no matter how creative, which can make up for this. It wouldn't be acceptable for a navy pilot to have dropped messages, and I think taking extreme edge cases like this is a good way to see how we really feel about such problems. And I don't believe pilots are the only folks with mission critical things to communicate. |
@jbenet in terms of making the faq discoverable, I think organising it under a bunch of broad headings and making it prominent in ipfs.io (in the same way as support pages on other sites) would be good 👍 to forums on IPFS. I've mentioned the "POST" idea to the Matrix folks (cc @ara4n) who I think will have some valuable input on this. Note that whilst matrix is currently mostly being used for decentralised chat, they also have longer term plans for decentralised forums, etc. They're also very interested in bridging existing silos into the decentralised network, which reduces a lot of the friction of adoption. |
@davidar I like this idea (in practice), of having a list of questions on ipfs/ipfs/README.md FAQs
I just think a solution like this (which has half data on ipfs/faqs and half on ipfs/ipfs) is going to put us in a situation where it's waiting to become inconsistent |
@mekarpeles personally I would migrate concrete answers out of ipfs/faq and only leave the new/unresolved questions, but that might require some work |
@davidar interesting, we could also experiment with having (on ipfs/ipfs) a list of links to issues, and making sure questions have corresponding issues. This way we don't need a FAQs doc at all and can manage answers w/ and w/o answers. Some FAQ items may seem more like threads than answers though... |
@jbenet that is a great idea! I'm working on my discussion boards in the same way. I'm separating:
I also have plans to extend the data structure a lot. This will include things like real time chatting, git repo hosting, any kind of media support, tags, a search engine, reputation system... These are just plans. I'm now implementing the basics. I can't wait to see what you've been working on in this context! I think since we are pretty much doing the same thing, we should communicate more, maybe we can help each other solve different problems. Or maybe ditch mine and use yours (which is probably better) seeing that my app is built so that replacing a layer is as easy as it can be. There is no data structure logic in the app, it's abstracted away in a separate API |
@mekarpeles nice to meet you too 👍 I'm very glad to be invited. These days I'm staying up late, so I think I will make it |
Hello everyone I haven't met yet @fazo96 @mekarpeles @haadcode o/ Happy to help develop the IPFS communication web application. I've been working a great deal with smart contracts as a distributed data syncing system over IPNS. This actually gives nice properties such as identity and post permissions inherited from bitcoin that work atm. However it costs money to post which sucks so I have been and would love to work more with others on an IPNS solution.
I've been hearing about this, great! Can't wait to learn more about what you guys are cooking up. I'll be in the discussions on IRC and hangouts today. |
@nginnever Hello! Nice to meet you 👍 I've been working on exactly that: a communication web application (fully static: no backend needed) that works over IPFS and IPNS only. The prototype is coming along nice: I managed to find solutions to most common problems with this kind of projects but not everything is perfect yet. The biggest problem is that it will be very hard to scale: the client needs to aggregate everything alone because there is no blockchain and all data is scattered across different sources. This can be a big problem when the numbers go up and there's a lot of data I'd be really really glad if someone else other than me had the time to look over my protocol and ideas at the github repo Also soon after IPFS 0.4 is ready I plan to get the prototype to the point where it can be used seriously 👍 |
@fazo96 Actually started reviewing your repo this morning. Really good ideas you have going. And you're right, getting consensus at scale could be difficult and why I have been using blockchains even though they are expensive and currently it takes ~12 second block times to sync the data (Which would lower with Ether POS but still hard to get block times down to sub-second confirmations). I'll give it some more thought and let's share some ideas on IRC or hangout today! |
cc @harlantwood |
👍 to getting something working on IPFS |
Fantastic discussion today: |
Just for the record, we (discourse.org) would be happy to host the IPFS community for free. I'm a big fan of the IPFS project and have been casually following it for some time. Today I happened upon the "Community" section of your docs and I found it quite daunting. I wanted to get an idea of the latest going-ons in the community, but in order to do that I had to:
I think these discussions would be a lot easier for newcomers to catch up on and get into if they took place in a purpose-built platform such as Discourse. @fazo96's discussion board project looks really cool, but as I'm sure he realised, making a scalable and user friendly forum platform takes a lot of time and effort. A decentralised platform is definitely more in line with the IPFS ethos, but it's not like you have to check all these boxes right out of the gate. Discourse offers exhaustive data exports, so you could take your data and leave when good and ready.
Wasn't the idea originally suggested here to converge on one platform exactly so that there would be fewer notification sources? If you used Discourse, none of your "discussion repos" would have to exist, nor would your Google Group. We have migration paths for both: They're not perfect, because the data accessible to us is limited, but the most important thing is just getting the content moved over so the new forum doesn't start out as a ghost town.
I'd love to know which communities you're referring to. Communities like Rust and Atom.io have been using Discourse very effectively, and even as a response to GitHub Issues getting too discussion oriented. |
Discourse is an excellent platform for what is currently missing for IPFS community, a living example is Caddy Community forum, that while introducing more noise yields a lot more fruits that would not as easily grow anywhere else. Personally I find Discourse easy to navigate, handle, manage, and inline code from github makes managing help a better experience. As someone that is trying to keep outlook consistently, I thought I will chime in. Reactions
I would implement a means of search over all github issues on all ipfs (and optionaly related) repos. Finding anything in general from a user / third-party dev perspective is very daunting.
I would think about closing/migrating google groups to Discourse
Very hard to navigate, hard to find relevant answers, documentation and materials,
Github is an excellent place for ipfs developer and contributor issues/discussions. |
We discussed this on today's all-hands call. There is a lot of interest in doing a trial run with discourse to see if it's a good fit for us. See #190 to participate in that experiment and/or to follow along. |
Notes from discussion about discourse during today's sprint call: Discourse - To kill or not to killIf we do this, github will still handle feature requests, bug reports, design discussions, or any other discusions that are aimed at discrete tasks or improvements. By contrast, Discourse wil be our platform for Q&A and also the primary platform for asynchronous open-ended community discussions, or any other discussions that are not aimed at a discrete task. David: need to list out the actions to get discourse to work:
Discussion:
|
We will finalize the decision about Discourse on Friday 17 March 2017. I've made a decision document that we can use to finally pull the trigger on this decision. See #246 If you have modifications to the proposal, modifications to the background information or if you want to block this proposal and argue for an alternative, please speak up before Friday. |
thank you @flyingzumwalt for pushing forward on this! |
We finalized this decision. We're going to use discourse. All the info is at https://github.com/ipfs/community/blob/master/decisions/community-forum-platform.md#decision |
Don't forget about https://www.discourse.org/github for the moving process! More about it here: https://meta.discourse.org/t/introducing-github-issues-to-discourse/46671?u=erlend_sh |
I suggested in irc earlier that it would make sense to have one place for the IPFS community to discuss and share, instead of having the current mix of different github repos + mailing list. Similar to how Maidsafe and rust do it my suggestion is using a discourse instance for this.
Extract from IRC below:
The text was updated successfully, but these errors were encountered: