A technical education site that teaches something incorrect is worse than one that has not covered the topic at all — the reader acts on it.
Corrections are the most valuable feedback this site receives, and they are prioritised above new content.
What to report
Section titled “What to report”Incorrect commands. A command that does not behave as the lesson describes, produces different output, or fails outright. This is the highest-priority category and is treated as a defect.
Outdated instructions. Installation steps, package manager commands and vendor interfaces age. Version-sensitive lessons record what they were verified against; if one has drifted, that is worth reporting.
Deprecated or changed platform features. A GitHub feature that has been renamed, moved, restricted to a different plan, moved out of preview, or removed. Platform behaviour changes faster than anything else on this site.
Inaccurate version or limit information. A documented limit, supported version, or plan availability that no longer matches the vendor’s own documentation.
Broken links. Internal links are checked mechanically on every build, so these are usually external — a vendor document that has moved or been retired.
Security concerns. An example that is insecure, a practice that has become unsafe, or a credential-handling pattern that should not be recommended. See the note below.
Outdated screenshots or interface descriptions. Where a lesson describes where to find a setting and that description no longer matches the interface.
Typos and unclear explanations. Lower priority than the above, still genuinely welcome. An explanation that is technically correct but misleads by simplification is a defect, not a matter of taste.
What makes a report actionable
Section titled “What makes a report actionable”A report that contains these can usually be reproduced and fixed without any back-and-forth:
-
The page URL. The exact page, and the section if the page is long.
-
The command you ran, exactly as you ran it.
-
The output you got, and what the lesson said to expect.
-
Your environment —
git --version, operating system, and where relevant the GitHub plan (Free, Pro, Team, Enterprise Cloud, Enterprise Server and its version).
For a documentation discrepancy rather than a command failure, a link to the vendor documentation that contradicts the lesson is the most useful thing you can include.
How to report it
Section titled “How to report it”The most useful place to report a technical error is the page it appears on — note the URL, the command you ran and the output you got, and send it through whichever channel below fits.
For corrections specifically, the corrections policy explains what makes a report actionable and how quickly different classes of error are handled.
How reports are handled
Section titled “How reports are handled”Technical errors are prioritised over new content. A published lesson that teaches something incorrect is a defect, and defects come first.
Categories are triaged differently:
| Class | Treatment |
|---|---|
| Incorrect command or output | Highest priority. Verified by re-running, then corrected. |
| Security concern in an example | Triaged first, before other technical reports. |
| Deprecated or changed platform behaviour | Checked against current vendor documentation, then corrected. |
| Outdated version or limit | Re-verified against the primary source and updated. |
| Broken link | Corrected or removed. |
| Typo or unclear wording | Batched and fixed. |
Every correction is verified before it ships. A reported fix is re-tested in a disposable repository the same way the original was, rather than applied on the strength of the report.
Substantive corrections update the page’s modification date. Lesson dates come from the actual change history of the source file, so a corrected page shows a genuinely newer date — the date is evidence, not decoration.
Not everything reported becomes a change. Sometimes the lesson is right and the difficulty is that it explained something poorly, in which case the explanation changes rather than the facts. Sometimes a report describes intended behaviour. Where a report does not result in a change, that is not a judgement on the report — ambiguity worth reporting is worth knowing about.
What this page is not
Section titled “What this page is not”It is not a help desk. This site is a publication. There is no capacity to debug individual repositories or answer general “how do I do X” questions — the contact page lists better places for those.
It is not a feature request queue, though suggestions for topics to cover are welcome and are read.