Feature Name
contribute-link
Description
The end result that I'd love to see is primarily for article content - I'd like to be able to include some directive that handles a bit of the mapping for where article content comes from that links back to where the content is hosted (such a GitHub, GitLab, etc) to make it easy and direct to provide a visual element that links to "edit this page".
For symbol content, this is notably trickier, and I haven't dig through to see/understand if the information we'd need is even included in SymbolGraphs, or how to handle it when the symbols are extracted from a precompiled binary. You've got the "where it came from" in the symbol graph data, and possibly, but certainly not always, any overrides that might exist in markdown from within a DocC catalog.
Getting the only pieces to add in a directive for page metadata for a specific article, or catalog metadata asking for it to be displayed across all articles in the catalog, would be a lovely win - alongside the DocC-render display pieces for this to provide a consistent-with-themed bit of detail that could be displayed inline, but unobtrusively, with the article. (other content that supports this typically does so at the top - often on the trailing side of content)
Motivation
There's already source-repository connections supported in DocC (from docc convert):
SOURCE REPOSITORY OPTIONS:
--checkout-path <checkout-path>
The root path on disk of the repository's checkout.
--source-service <source-service>
The source code service used to host the project's sources.
Required when using '--source-service-base-url'. Supported values are 'github', 'gitlab', and 'bitbucket'.
--source-service-base-url <source-service-base-url>
The base URL where the source service hosts the project's sources.
Required when using '--source-service'. For example, 'https://github.com/my-org/my-repo/blob/main'.
But the user experience is sub-par (still quite high friction) for providing a very direct way for a reader to see a typo or mistake, and being able to quickly open a page on GitHub (or where-ever the source is hosted) to suggest an edit to fix that content issue.
My goal is to make is as easy as humanly possible to fix minor documentation flaws and encourage community participation in the content maintenance.
Importance
No response
Alternatives Considered
No response
Feature Name
contribute-link
Description
The end result that I'd love to see is primarily for article content - I'd like to be able to include some directive that handles a bit of the mapping for where article content comes from that links back to where the content is hosted (such a GitHub, GitLab, etc) to make it easy and direct to provide a visual element that links to "edit this page".
For symbol content, this is notably trickier, and I haven't dig through to see/understand if the information we'd need is even included in SymbolGraphs, or how to handle it when the symbols are extracted from a precompiled binary. You've got the "where it came from" in the symbol graph data, and possibly, but certainly not always, any overrides that might exist in markdown from within a DocC catalog.
Getting the only pieces to add in a directive for page metadata for a specific article, or catalog metadata asking for it to be displayed across all articles in the catalog, would be a lovely win - alongside the DocC-render display pieces for this to provide a consistent-with-themed bit of detail that could be displayed inline, but unobtrusively, with the article. (other content that supports this typically does so at the top - often on the trailing side of content)
Motivation
There's already source-repository connections supported in DocC (from
docc convert):But the user experience is sub-par (still quite high friction) for providing a very direct way for a reader to see a typo or mistake, and being able to quickly open a page on GitHub (or where-ever the source is hosted) to suggest an edit to fix that content issue.
My goal is to make is as easy as humanly possible to fix minor documentation flaws and encourage community participation in the content maintenance.
Importance
No response
Alternatives Considered
No response