-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get a basic README in place #21
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
brandur
force-pushed
the
brandur-readme-2
branch
2 times, most recently
from
November 13, 2023 14:35
37da02f
to
965f53a
Compare
Alright, so I don't love this, but here, aim to get a basic River README in place for GitHub friendliness, largely via duplication. Godoc is odd to say the least. These days it does dump a project README automatically into godoc if one was present, but it's always a second class citizen: it's collapsed when the user first visits the doc page, and doesn't offer some niceties like the TOC that's generated for `doc.go`. I searched around, and there's no easy compromise that gets the best of both worlds. So here: * Move old README to `docs/development.md`. * Make edits to `doc.go` so that it's more agnostic as to whether it's in godoc or rendered Markdown. * Streamline the old `doc.go` somewhat for length. Add list of features that link out to our docs. * Copy `doc.go` largely unedited to `docs/README.md`. The trick with `docs/README.md` is that GitHub will still find a README there and render it as the top level of a project, but godoc _won't_ find it and dump it into godoc (so we don't accidentally duplicate the content twice in godoc). On the way from `doc.go` to `docs/README.md` I made a couple small tweaks for GitHub friendliness: * Gave it an h1 of "River". * Added badges. * Starts with "River is a" instead of "Package River is a". * Dedented all the headings. One thing that sucks about godoc is it won't render anything except an h1-level heading, but these look way too screamy in most Markdown renderings. * Made all the code blocks Go-formatted. Godoc won't respect the three backtick syntax for codeblocks, so we can't use that there, but we also can't specify a language _without_ using them for GitHub. Obviously, this isn't a great situation. I tried the use of the goreadme tool in #19, but that comes with significant problems that aren't fixable without issuing them pull requests. For now, I propose that we duplicate changes manually between the two documents while making them, and eventually write our own tool to do the duplication. This is easier than it sounds because we can leverage Go's internal tool for parsing godoc.
brandur
force-pushed
the
brandur-readme-2
branch
from
November 13, 2023 14:36
965f53a
to
60f0db2
Compare
@bgentry Not calling this perfect, but wanted to lock something into place that we could start sending around to people. Mind taking a looking? |
bgentry
approved these changes
Nov 13, 2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great to me!
Awesome! TY. |
brandur
added a commit
that referenced
this pull request
Nov 14, 2023
Follows up #21 with a few very small documentation fixes: * Put the link to the development doc into its own section so that it looks less strange when following the list of features just before it. * Promote the "development" header in the `development.md` up to h1 since it's now a file only for development instructions. Promote all the other headers to h2.
brandur
added a commit
that referenced
this pull request
Nov 14, 2023
Follows up #21 with a few very small documentation fixes: * Put the link to the development doc into its own section so that it looks less strange when following the list of features just before it. * Promote the "development" header in the `development.md` up to h1 since it's now a file only for development instructions. Promote all the other headers to h2.
brandur
added a commit
that referenced
this pull request
Nov 14, 2023
Follows up #21 with a few very small documentation fixes: * Put the link to the development doc into its own section so that it looks less strange when following the list of features just before it. * Promote the "development" header in the `development.md` up to h1 since it's now a file only for development instructions. Promote all the other headers to h2.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Alright, so I don't love this, but here, aim to get a basic River README
in place for GitHub friendliness, largely via duplication.
Godoc is odd to say the least. These days it does dump a project README
automatically into godoc if one was present, but it's always a second
class citizen: it's collapsed when the user first visits the doc page,
and doesn't offer some niceties like the TOC that's generated for
doc.go
. I searched around, and there's no easy compromise that getsthe best of both worlds.
So here:
docs/development.md
.doc.go
so that it's more agnostic as to whether it'sin godoc or rendered Markdown.
doc.go
somewhat for length. Add list of featuresthat link out to our docs.
doc.go
largely unedited todocs/README.md
.The trick with
docs/README.md
is that GitHub will still find a READMEthere and render it as the top level of a project, but godoc won't
find it and dump it into godoc (so we don't accidentally duplicate the
content twice in godoc).
On the way from
doc.go
todocs/README.md
I made a couple smalltweaks for GitHub friendliness:
won't render anything except an h1-level heading, but these look way
too screamy in most Markdown renderings.
backtick syntax for codeblocks, so we can't use that there, but we
also can't specify a language without using them for GitHub.
Obviously, this isn't a great situation. I tried the use of the goreadme
tool in #19, but that comes with significant problems that aren't
fixable without issuing them pull requests.
For now, I propose that we duplicate changes manually between the two
documents while making them, and eventually write our own tool to do the
duplication. This is easier than it sounds because we can leverage Go's
internal tool for parsing godoc.