docs: point the community section at Discussions, and drop an orphaned blog page - #9
Conversation
"Join our community" offered two buttons, GitHub Issue and GitHub Pull
Request. Neither is a way to join anything — one reports a problem, the
other submits finished work — and the line above them ("Be part of a
growing ecosystem of developers who care about Commit Check") said
nothing a reader could act on.
Discussions is enabled on the engine repository and both READMEs already
send people there, but the site never mentioned it. It is now the primary
button, and each channel says what it is for: discussions for weighing a
policy or an unclear bug, issues for something broken, pull requests for
any of the repositories.
Also drop docs/blog/author/team.md. It was an orphan — nothing linked to
it, it was not in the nav, and it matched no key in .authors.yml, so the
blog never rendered it as an author page. It described "a small group of
people" where that file lists one. It was also the reason every build
printed a page-not-in-nav notice. A redirect stub covers the URL, the
same treatment the other retired pages get.
The blog index said "News, updates, and resources from the commit-check
organization", which does not tell anyone whether to read it. It now says
what the posts are for and how they differ from the reference pages.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U9zFxq8V4qxG4aMzJhGBFn
✅ Deploy Preview for commit-check ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Warning Review limit reached
Next review available in: 30 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
2 participants
What
Two more items from the structural review: the community section, and the blog.
The community section pointed at everything except the community
"Join our community" offered two buttons — GitHub Issue and GitHub Pull Request. Neither is a way to join anything: one reports a problem, the other submits finished work. The line above them, "Be part of a growing ecosystem of developers who care about Commit Check", gave a reader nothing to act on.
Meanwhile Discussions is enabled on the engine repository (
has_discussions: true, confirmed via the API) and both thecommit-checkandcommit-check-actionREADMEs already send people there — the site was the only place that never mentioned it.It is now the primary button, and each channel says what it is for:
--format jsonoutput attacheddocs/blog/author/team.mdwas an orphanNothing linked to it, it was not in the nav, and it matched no key in
.authors.yml— the posts are authored byshenxianpeng, so the blog plugin never rendered it as an author page. It described "a small group of people" where that file lists one person.It was also the reason every build printed:
Removed, with a redirect stub for the URL — the same treatment the other retired pages get in
scripts/mkdocs_hooks.py. That notice is now gone from the build.The blog index did not say whether to read it
"News, updates, and resources from the commit-check organization" describes every blog ever written. It now says what these posts are for and how they differ from the reference pages: the reference tells you what a rule does and how to configure it, the posts cover why it exists and what changed along the way.
Test plan
mkdocs build --strictclean, and the page-not-in-nav notice no longer appearshttps://commit-check.com/blog/#ecosystemanchor verified in the built outputNote
While writing the community section I claimed the rules reference says which repository owns a given behaviour. It does not — checked, and corrected to point at the Ecosystem section on the same page instead.
The proxy here blocks external hosts, so I could not open the deploy preview; everything above was checked against a local build.
Still open from the review: the "Trusted by" wording (needs your judgement on real-world usage), the Ecosystem diagram's weight, and a
--compactoutput inconsistency that belongs upstream incommit-check.Generated by Claude Code