# Objective
Oftentimes I find myself reading through a PR and not quite
understanding what's going on. Even if it's super detailed, it can
sometimes be difficult to imagine what the end result of the PR might
look like.
For example, #10756 clearly communicates its goals and contains a
descriptive Changelog. However, I was still a bit lost as to what a user
might see from the change until I saw the dedicated example in the diff.
## Solution
At the risk of giving contributors more work, I think a dedicated
`Showcase` section could be really nice.
Along with providing reviewers stumbling on the PR with a "tangible
summary" of the change, it should also help out when working on the
release post. Sometimes someone other than the PR's author has to write
up a blog section on the PR. This can be somewhat daunting to people
wanting to contribute in that effort as they have to rely on the
Migration Guide giving a decent example (assuming it's a breaking
change), piecing together the other sections into a sensible example
themselves, or manually reading through the diff.
Theoretically, this new `Showcase` section would be more of an
encouragement than a strict requirement. And it's probably only going to
be useful where there is something to showcase (e.g. visual changes, API
changes, new features, etc.).
### Bikeshedding
- **Naming.** I also considered `Demo` and `Example`, but there may be
others we prefer. I chose `Showcase` to communicate the feeling of fun
and appreciation for the work contributors put in.
- **Position.** I placed the section right above the `Changelog` section
since I felt it made sense to move from the details in `Solution` to a
brief example in `Showcase` to a tl;dr of the changes in `Changelog`
- **Phrasing.** We can also bikeshed the bullet points and phrasing of
each as well.
# Objective
This fails constantly and causes more pain than it is worth.
## Solution
Remove dead link checks.
Alternative to #4837, which is more granular but ironically still fails to build. I'm in favor of the nuclear option.
Fixes#4575
# Objective
- related to #4575, but not a complete fix
- links to GitHub.com can't be checked from inside a GitHub Actions as GitHub is protecting itself from being flooded by an action execution
- it seems they added that protection to GitHub doc site
## Solution
- Ignore links to docs.github.com
Adds an GitHub Action to check all local (non http://, https:// ) links in all Markdown files of the repository for liveness.
Fails if a file is not found.
# Goal
This should help maintaining the quality of the documentation.
# Impact
Takes ~24 seconds currently and found 3 dead links (pull requests already created).
# Dependent PRs
* #2064
* #2065
* #2066
# Info
See [markdown-link-check](https://github.com/marketplace/actions/markdown-link-check).
# Example output
```
FILE: ./docs/profiling.md
1 links checked.
FILE: ./docs/plugins_guidelines.md
37 links checked.
FILE: ./docs/linters.md
[✖] ../.github/linters/markdown-lint.yml → Status: 400 [Error: ENOENT: no such file or directory, access '/github/workspace/.github/linters/markdown-lint.yml'] {
errno: -2,
code: 'ENOENT',
syscall: 'access',
path: '/github/workspace/.github/linters/markdown-lint.yml'
}
```
# Improvements
* Can also be used to check external links, but fails because of:
* Too many requests (429) responses:
```
FILE: ./CHANGELOG.md
[✖] https://github.com/bevyengine/bevy/pull/1762 → Status: 429
```
* crates.io links respond 404
```
FILE: ./README.md
[✖] https://crates.io/crates/bevy → Status: 404
```
I have run the VSCode Extension [markdownlint](https://marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint) on all Markdown Files in the Repo.
The provided Rules are documented here: https://github.com/DavidAnson/markdownlint/blob/v0.23.1/doc/Rules.md
Rules I didn't follow/fix:
* MD024/no-duplicate-heading
* Changelog: Here Heading will always repeat.
* Examples Readme: Platform-specific documentation should be symmetrical.
* MD025/single-title
* MD026/no-trailing-punctuation
* Caused by the ! in "Hello, World!".
* MD033/no-inline-html
* The plugins_guidlines file does need HTML, so the shown badges aren't downscaled too much.
* ~~MD036/no-emphasis-as-heading:~~
* ~~This Warning only Appears in the Github Issue Templates and can be ignored.~~
* ~~MD041/first-line-heading~~
* ~~Only appears in the Readme for the AlienCake example Assets, which is unimportant.~~
---
I also sorted the Examples in the Readme and Cargo.toml in this order/Priority:
* Topic/Folder
* Introductionary Examples
* Alphabetical Order
The explanation for each case, where it isn't Alphabetical :
* Diagnostics
* log_diagnostics: The usage of inbuild Diagnostics is more important than creating your own.
* ECS (Entity Component System)
* ecs_guide: The guide should be read, before diving into other Features.
* Reflection
* reflection: Basic Explanation should be read, before more advanced Topics.
* WASM Examples
* hello_wasm: It's "Hello, World!".
