Using Discourse as a internal Knowledge Base / Intranet


(George Guimarães) #1

Anyone using Discourse as a internal Knowledge Base for a company?

Think about discussing “how we do stuff at the company” and then curating the content to be a live version of it. (maybe that’d be similar to a wiki, but with more discussion around it).

I’d love to hear about the kind of categories you are using, which settings makes more sense and so on.


Using Discourse to host a Knowledge Base
(Matt Palmer) #2

In the spirit of eating our own dogfood, we at Discourse use Discourse as our internal KB. It’s part of the same internal-only Discourse that we use for discussion of “everything else” that can’t be public (what to do about the gopher problem in the crawlspace, that kind of thing).

Our categories (and sub-categories) are more-or-less along the usual “department” lines: ops, dev, biz, gophers, etc. As far as settings go, I don’t think we do anything particularly different to what any other Discourse instance might have. One thing we do use fairly heavily is comment deletion. While plenty of comments do get left on KB topics, if the “main article” is edited to incorporate (or otherwise “handle”) the contents of a comment, that comment will often be “nuked”, just to keep things clean. So, you’ll want to give everyone sufficient powers to be able to do that.

Depending on the past experience of your team, you may need to reinforce that editing the main article is not just permitted, but in fact encouraged, by everyone on the team. For people who are used to forums, but perhaps aren’t quite as used to wikis, they may feel that etiquette demands that they not modify “someone else’s” post, but instead make a comment. The best analogy I can make there is that handling your KB like that would be like trying to build software by applying every diff file every time someone wanted to compile it. Madness.

One thing that does get in the way a little bit is “superceded” topics. While we tend to “edit in” changes to existing topics, there are occasions where it makes more sense to “shut it down” and start again with a new topic. In that case, the “old” information is still sitting there for anyone to stumble across, amongst more relevant search results. You can edit the title of the old topic to flag it as “out of date”, but @sam has plans (when a future shipment of round tuits comes in) to “weight” topics in the search results, to deprioritise (or hide completely) topics that are marked as “superceded”.

Hope that helps. Feel free to ping back with any other questions or thoughts you have. Knowledge management is a bit of a passion of mine; comes from being married to a librarian, I guess.

(Gummibear) #3

It sounds a bit like growing a wiki starting with forum discussions.

How can I see Discourse as a wiki? Is there an entry page for the wiki, a recent changes list? A list (index) of all wiki pages?

(Sebastian) #4

Oh man this is inspirational… I had a client recently that was looking for a system, and now that I think of it, it could’ve been accomplished perfectly with Discourse

(Matt Palmer) #5

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.

(Matt Palmer) #6

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.

(Clay Heaton) #7

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.

(George Guimarães) #8

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.

Is anyone working on a Discourse Wiki?
(Matt Palmer) #9

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.

(Allen - Watchman Monitoring) #10

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:


(Pugwash) #11

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!

(David García-Navas) #12

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 :smile:
  • 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 :smile:
  • Meta, Development and Staff, similar than here on

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 :discourse: 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 :smile:

Btw, i’m open to questions, we’re using Discourse since december’13!

(Erlend Sogge Heggen) #13

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.

(David García-Navas) #14

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 :discourse: team a free printed copy if you want but it’s written in spanish - it was published in january’15):


[…] 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…


…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 :smile:

(Allen - Watchman Monitoring) #15

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?

(Matt Palmer) #16

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.

(Allen - Watchman Monitoring) #17


I’d love to use this as an excuse to standardize on discourse for our user manual & discuss forum.

(Tom Newsom) #18

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 :slight_smile:

(Ryan Nix) #19

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

(Jae Van Rysselberghe) #20

I recommend to check out this topic thread if you haven’t already: