The entry page is the front page, with a list of all topics. The recent changes list is the same page – the most recent changed topics will bubble up to the top. I’ve never, in a non-trivial wiki, seen value in a list of all pages, because there’s just too damn many of them. You need either good search or good categorisation to make sense of the volume of information in a wiki; I’ve previously used hierarchy and tagging, but Discourse’s own search is working pretty well so far to find info, so I’m hopeful that it’ll remove the need for strict, manual categorisation.
Using Discourse as a internal Knowledge Base / Intranet
1 Like
I’ve got to say, I was a bit skeptical on my first day at Discourse. The conversation went something like this:
Me: “Where’s the wiki?”
Old-timer: “Here’s our internal Discourse instance”
Me: “Yeah, cute you’re eating your own dogfood, but this’ll never work”
OT: “Try it for a while, see how you like it”
Me: “OK, but I’ll have this stuff in gollum inside a week, I’ll bet…”
Turns out, it works pretty damn well. Still haven’t felt a need to setup gollum.
8 Likes
That is precisely how we use it, intranet only. Our work is primarily project-based, sometimes with projects under NDA, so we have a Projects category and tend to create access-restricted subcategories of Project for individual project work. We also have broader topics that cover thematic issues that span projects, such as “Health Care,” “Criminal Justice,” etc.
Sometimes we use wiki posts at the top of topics. For instance, we have dozens of internal prototypes and tools running on various ports of a dev machine. We use a wiki post in a pinned topic to track which ports are in use for which project. In general, I find the wiki posts to be less useful for larger discussions.
Overall, Discourse is a huge hit at my company.
5 Likes
Thanks for the reply Matt.
I think I’ll go with something like you describe. I haven’t thought about the comment and editing part, but it makes sense.
The way I thought goes more like opening topics questioning stuff (“How do we do X here?”) and then after some discussion I’d split the relevant comments into another topic with a more affirmative sentence.
But that’s too much trouble. I guess editing the topic should be easier.
My main pain with wikis and “traditional” KB is that there’s too much focus on the content, but not much on the discussion (“is this way still the way to go on doing X for Y?”) . And since new stuff gets created and updated, Discourse seems a good fit for the discussion.
Well, let me setup things here. I’m excited to try it.
Yeah, many wikis are focused very tightly on publishing, and not at all on interaction. The three things that make discourse a good choice for documentation in my mind are:
- Non-sucky search. So far, when I’ve needed to find something in our KB, I’ve found it, or gotten confirmation from others that it doesn’t exist at all. I don’t think I’ve been handed a URL to a topic that I’d not found.
- Discussion. Yes, documentation should stand alone. But it never does. Especially for a remote team (which Discourse is), the ability to incorporate async communication into the documentation is immensely valuable.
- Likes. I’ve blogged about this in the past, that you can encourage people to write more documentation if there’s a positive feedback loop incorporated into the process (as opposed to the usual negative-only loop of only ever hearing, “this didn’t work for me, WTF?”). The simple act of “click the heart if this was helpful”, if the whole team gets on board with it, is possibly the single biggest encouragement to write good documentation that you’ll have.
As far as your process goes, I wouldn’t suggest that you mandate “ask a question, then turn it into a standalone page”. That would be good to do when it spontaneously happens, but I think it works quite well to just write a topic, straight up, explaining what you want to tell everyone, with no expectation of answers. Basically, whenever you’d normally think, “I should write a wiki page about that”, click “New Topic” and go to town. It’s how I’ve been doing it so far, and it seems to be working well.
9 Likes
I intend on using Discourse for this as well. May even replace mindtouch (a 10k+ a year solution).
Things I think we need are planned:
and
1 Like
I’ve been working on a KB mock-up that uses deep linking anchors (example page here, CSS/HTML templates here), amongst a few other things, namely:
- Left hand navigation menu.
- Hidden avatars and topic meta data.
- Paired down topic lists.
It’s all hard-coded and desktop only at the moment. Still a work in progress!
7 Likes
I will create a topic with the long story of how our organization switched to Discourse as a internal social platform on praise category, but, focusing in what @georgeguimaraes asks, i’ll try to post here the main details of our intranet with Discourse:
A bit of context:
- We came from a facebook-like tool (Socialcast) so we created the categories from scratch at the same time we adapt to the forum paradigm.
- The organization we work for, Tc, it’s an hybrid between a creative agency and a digital transformation consulting & services organization.
The categories we have in order to organize content:
- Tc (name of the company), where all the information about ourselves goes in, and multiple subcategories such as “welcome to tc” for meet new workmates, “projects”, where we share the business news; 2 blogs by the corporate and the executive directors; “press” with the posts in the media that talk about us and so on…
- Strategy: here we talk about a myriad of topics but focused on the future of our company (digital trends) of our customers (finance, automotive, airlines, telecommunications…)
- Methodologies: how-to’s, new ways to do something or changes in tools, apps, ask&help. As Tc, this category contains multiple subcategories with the different areas of our work.
- Creativity: inspirational campaigns that other agencies do and a specific subcategory as a repository of the campaigns we do at the same time.
- Off-topic: whatever
-
Pedia: our Knowledge Base project, just starting to grow. Similar than Methodologies, but in this we have not discussion, obviously. Our initial approach was to create index-style topics that links to another topics listed on Methodologies. But little by little we’ll replacing links by it’s own wiki-style content.
I’ve seen the @Pugwash mock-up and i thinks it’s a excellent idea so perhaps we’ll adopt.
pd. @pugwash thanks for share the code, i’ll take a look on Quick File
- Meta, Development and Staff, similar than here on meta.discourse.org.
We are thinking about how tags feature could help us to organise the content, but until now we have not use that.
Recent changes
Some of the recent 
features helped us specifically on knowledge management objetive very much: hide a category from latest (with this, Pedia category and its sub-categories don’t mix with discussion categeories on the homepage), the better full search, html tables in posts and html anchors to create table of content.
We are even happier to know than in 1.5 release Discourse will have better support for tables with new markdown flavor and better html anchors. We feel in debt with this great team so until we become customer for some great-budget project we at least recommend this software in every way.
In short
Our culture was already ready to share knowledge and ideas but this beautiful software boosted the quality of discussion and encouraged everybody to contribute inside the organization. As i mentioned at the first paragraph, i have a to-do called “publish a praise-category topic on meta.discourse to communicate our experience with Discourse” - i’ll do as soon as i can because it’s an interesting story
Btw, i’m open to questions, we’re using Discourse since december’13!
11 Likes
Besides the ones already mentioned, what are some knowledgebase features that you miss the most?
This sounds like it might make for a good guest blog post @codinghorror.
1 Like
We would love to!!
I don’t know if it’s possible due to having a self-hosted instance (non customers), but our story with Discourse is so interesting that we publish it in a book about our culture and management (we can send to the team a free printed copy if you want but it’s written in spanish - it was published in january’15):
Translation:
[…] After a full year of time invested in a own development to make a Drupal adaptation to run as our internal social network, DavidGNavas insisted on proving that we should evolve to a recent-creation GPL software called Discourse. Hours of research led him to understand…
/nextpage/
…the advantages, features and how fast was the related community growing, so, after a test on a dedicated server, he showed that he was right. We decided to cut off the budget invested on Drupal and, overall, the emotional link with a project that we had been working for a year. […]
-
Mentioned here on meta: better support for making groups of wiki authors. Nowadays you can set permissions for a category but it you make a post wiki-style, you get permissions based on trust-level. A good idea would be a mix: group of allowed authors that can edit a wiki post.
-
Perhaps an avatar list of who have contributed to the wiki topic.
Various ideas from @sam in potencial plugins topic:
- An integration with a to-do app or an own to-do list.
- The reactions plugin. We have several topics about “who comes to a lunch with foo…?”
pd. we don’t have trouble with javascript/Android because our organization provide us an iPhone while we work here
11 Likes
The decision is again upon us… to use Discourse or Mindtouch for our primary knowledge base.
I’d love to spend 1/5 the cost of Mindtouch’s cost, but their ability to create html-anchor based table of contents on the fly, vs Discourse’s inability to use them, is an issue.
Anyone else willing to pay for discourse hosting to get this feature this Quarter?
Is the ToC the only pertinent thing that’s holding you back from using Discourse? Because I’ve got a few topics in our internal KB that could do with a ToC, so if someone else wants it too, I’ll use that as an excuse to make more noise about getting it into the next release.
7 Likes
Matt,
I’d love to use this as an excuse to standardize on discourse for our user manual & discuss forum.
2 Likes
I’d be very happy to see ToC and anchor support. So happy I went as far as this:
No idea if it’s any help 
5 Likes
Hey @mpalmer,
I’m really trying to convince my team that Discourse is a good solution for a Wiki/Discussion forum for our IT team and for the broader community that we serve.
Some of the push back has been against the layout, i.e. categories and sub categories. Could you or anyone else share some layout options? i.e. maybe some screenshots of Discourse being used as an intranet? One of the concerns against using Discourse is that there aren’t a lot of examples of Discourse being used internally. For me, everything you listed out is why I love Discourse so much as an internal solution. The search function is amazing, the email blasts are terrific and overall I like the community engagement factor. From an IT perspective it’s super easy to maintain too, which is key since none of us have a lot of time to build an maintain a new system.
Thanks for any insights.
- Ryan
1 Like
I recommend to check out this topic thread if you haven’t already:
1 Like
Thanks, @jaevanryssel. This definitely helps a bit. We use Slack too and so there has been some discussion on when Slack is appropriate vs Discourse.
funny that this thread is being reawakened now. I am working on this right now - we use discourse as a community forum and for internal staff discussions. I’d like to reconfigure things so it’s optimal for both, but it’s been a bit of a challenge. For example internal discussions swamp the frontpage for staff so sometimes it’s hard for them to see and deal with community discussions. For today I am trying out the “hide category from frontpage” setting and adding a link to that category on the top menu, visible only to staff.
I also am looking to create a wiki category with sub-categories, to contain operating procedures and how-to docs for staff. This is working well, especially with the “boxes with topics” category view - like the #howto category here - see screenshot. I like! I think it will be a big improvement over the google docs we were using previously for this purpose. Especially when considering that it can respect permissions and show people only the sub-category of procedures that they need to see according to their role.
Up next, I think, is to figure out a way to present the wiki topics in a structured interface externally, so it can be used without the distraction of discourse discussion features, safely also when discourse is down, and also perhaps even offline saved as structured PDFs.
The learndiscourse experiment might be a help for this - and if anyone has done it recently with success and has a recipe for it I’d love to see it! Sadly, learndiscourse.org is not working right now.
https://github.com/erlend-sh/learndiscourse/blob/gh-pages/about.md
7 Likes
This is great! I’m also thinking about using discourse as a KB. Only issue I’m seeing so far is localization, seems like that would be a bit more painful than the solution we have now.
There isn’t really a way to have a single topic localized is there?
1 Like
The same topic translated into multiple languages? Not really, no. Once you get to that kind of upscale requirement I think it’s time to transition to a specialized docs platform. Using something like https://www.gatsbyjs.org you could continue using Discourse as the data source for your English content, whilst translating the rest in Transifex.
3 Likes