Skip to content
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 1 commit into from
Nov 13, 2023
Merged

Get a basic README in place #21

merged 1 commit into from
Nov 13, 2023

Conversation

brandur
Copy link
Contributor

@brandur brandur commented Nov 13, 2023

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 brandur force-pushed the brandur-readme-2 branch 2 times, most recently from 37da02f to 965f53a Compare November 13, 2023 14:35
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
Copy link
Contributor Author

brandur commented Nov 13, 2023

@brandur
Copy link
Contributor Author

brandur commented Nov 13, 2023

@bgentry Not calling this perfect, but wanted to lock something into place that we could start sending around to people. Mind taking a looking?

@brandur brandur requested a review from bgentry November 13, 2023 14:38
Copy link
Contributor

@bgentry bgentry left a 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! :shipit:

@brandur
Copy link
Contributor Author

brandur commented Nov 13, 2023

Awesome! TY.

@brandur brandur merged commit 7644aad into master Nov 13, 2023
5 checks passed
@brandur brandur deleted the brandur-readme-2 branch November 13, 2023 14:53
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants