Problem Statement:
The project already has ESLint + Prettier configured for TypeScript/React code (confirmed via eslint.config.mjs and .prettierrc at root), and even maintains a dedicated community/understand-lint-checks.md guide — showing the maintainers clearly value consistent linting. However, this tooling only covers code, not the actual bulk of the repository's content: the docs/, blog/, and community/ Markdown files that make up the site's primary value as a learning platform.
Why this matters:
With such a large volume of Markdown content contributed by many different first-time GSSoC participants, inconsistencies naturally accumulate — inconsistent heading levels, broken code-fence language tags, trailing whitespace, or common spelling errors — none of which the existing ESLint/Prettier setup catches, since those tools aren't configured for .md content.
Proposed Solution:
Add markdownlint-cli2 (or similar) as a dev dependency with a sensible baseline config (e.g., allow long lines for prose, enforce consistent heading style and fenced code blocks).
Add cspell (or similar) for basic spellcheck on docs/, blog/, and community/, with a project-specific dictionary file for technical terms/brand names that would otherwise false-positive (e.g., "recodehive," "Docusaurus," "Codeforces").
Add both as a new job in the existing .github/workflows/ CI, non-blocking (warning-only) at first so it doesn't disrupt current contributors, with a path to making it required later.
Reference the new checks from the existing community/understand-lint-checks.md guide so contributors have one place to learn about all lint requirements (code and content).
Impact: Extends the project's already-demonstrated lint-quality culture to its actual primary content, improving consistency across a docs site maintained by a very high-turnover contributor base.
Problem Statement:
The project already has ESLint + Prettier configured for TypeScript/React code (confirmed via eslint.config.mjs and .prettierrc at root), and even maintains a dedicated community/understand-lint-checks.md guide — showing the maintainers clearly value consistent linting. However, this tooling only covers code, not the actual bulk of the repository's content: the docs/, blog/, and community/ Markdown files that make up the site's primary value as a learning platform.
Why this matters:
With such a large volume of Markdown content contributed by many different first-time GSSoC participants, inconsistencies naturally accumulate — inconsistent heading levels, broken code-fence language tags, trailing whitespace, or common spelling errors — none of which the existing ESLint/Prettier setup catches, since those tools aren't configured for .md content.
Proposed Solution:
Add markdownlint-cli2 (or similar) as a dev dependency with a sensible baseline config (e.g., allow long lines for prose, enforce consistent heading style and fenced code blocks).
Add cspell (or similar) for basic spellcheck on docs/, blog/, and community/, with a project-specific dictionary file for technical terms/brand names that would otherwise false-positive (e.g., "recodehive," "Docusaurus," "Codeforces").
Add both as a new job in the existing .github/workflows/ CI, non-blocking (warning-only) at first so it doesn't disrupt current contributors, with a path to making it required later.
Reference the new checks from the existing community/understand-lint-checks.md guide so contributors have one place to learn about all lint requirements (code and content).
Impact: Extends the project's already-demonstrated lint-quality culture to its actual primary content, improving consistency across a docs site maintained by a very high-turnover contributor base.