I’m just catching up with this thread—but I certainly think the answer is yes
Because of the success of our enterprise community (both with our users, and within our business) our documentation team reached out and asked if we could build a comment system for all of documentation.sailpoint.com. From the looks of it, we’ll be able to do almost everything we want to accomplish at a bare minimum:
Embed comments (embedding feature)
We also want to use different users to post as, and apply different sets of tags, based on the embedding. This feature is coming very soon:
From there, everything else the docs team (and my team) wanted was within Discourse for us to effectively segregate this experience from the rest of our “day to day” forum usage, while still giving people the ability comment, get notified of replies, etc.
Ability to designate which users can and cannot comment
Assign category moderators to the associated topics
Suppress this plethora of categories for these docs from our main site
category not searchable
theme component used to hide it from main category list
suppressed from digest
added to default muted categories
Comments removed after n days
A few other settings…
I definitely would love to see many of the features mentioned here implemented, though!
Is the goal to allow users to create comments on https://documentation.sailpoint.com/, or are you ok with just embedding the comments on the docs site and having users visit your Discourse site to comment on articles?
The former is a feature I’d welcome and love to have (read: please build, CDCK), but the latter meets our minimum requirements, at least.
I actually will be exploring an idea in the near future of having Discourse serve up our markdown documentation (no, not in topics, but in traditional markdown-style docs) in which case comments, and signing up to make them, would be all-inclusive. But that exploration hasn’t begun yet.
With the approach I’m working on now, it would be technically possible to allow Discourse comments to be generated directly on MkDocs pages, but it would require using a server side framework (Remix, Rails, etc) to serve the MkDocs pages. That would make it possible to authenticate users (with DiscourseConnect) on the docs site and also allow an in-memory database to be used for caching previously returned comments.
(Edit: just to be clear, I’m talking about using Discourse as an identity provider for the website, not the website as the identity provider for Discourse. The latter approach works, but it’s too inflexible for most use cases.)
That would be a big change to ask your team to make though.
I’m sure from your perspective it would be more straightforward if this was accomplished entirely inside of Discourse, but it’s also possible to use Discourse as a content management system. In that case, the markdown documentation would be generated as regular Discourse topics. Discourse webhooks would be used to trigger the generation of a docs page on an external site. That’s actually the basis of the Discourse comments demo site I’m setting up.
