A software project maintains its documentation in a Git repository.
The master version of a file is the canonical version of this documentation
We want to use Discourse to facilitate collaborative edition and criticism of the living document
Approach
Copy the link to the raw markdown file from the Git repository, e.g., https://git.example/org/documentation/raw/master/INSTALL.md in the new topic title field
Discourse retrieves title and markdown content that becomes topic content
Discourse watches for changes and rebuilds HTML when needed, maintaining versions
Then the readers always have access to the latest markdown version in Git, while editors can use the power of Discourse to discuss changes.
Down the road
When ActivityPub support is added to Discourse and Git (via ForgeFed), this type of integration can be expanded to include cross-application document synchronization, without the need to know about Git.
The first step is to “onebox” external markdown. This would as well allow to integrate with a static blog directly from it’s Git repository, consolidating the publication process (i.e., by generating topics matching static pages at publication time)
What current solutions (API calls?) exist to do this besides embedding comments on the static page? How far from embed.js would that lead us?
You cannot que not use any other Discourse feature on a link. The idea is to integrate the content, not just link to it.
Why not have native markdown instead? JavaScript can do that, right?
Just thinking ahead of the ActivityPub support: if instances can already have a mechanism to relay existing content from one another, it all gets easier to follow a single topic across instances, and to generate static sites from Discourse topics.
Set a crontab to watch wanted topics (and posts) for changes
Whenever a change happens, download the latest version to a Git repository (e.g., a static site) and commit that. You would download either the original Markdown version of the post (post_id.md) or the cooked version for HTML (but then you’d have to rewrite the URI to ensure all are absolute and thus contain the protocol and hostname of the Discourse instance.)
API documentation is useful, as well as the examples directory in the gem.