If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/freeCodeCamp/how-to-contribute-to-open-source shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Slowing — last commit 11mo ago

• Last commit 11mo ago
• 90+ active contributors
• Distributed ownership (top contributor 6% of recent commits)
• CC-BY-SA-4.0 licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 11mo ago
• ⚠ Non-standard license (CC-BY-SA-4.0) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live freeCodeCamp/how-to-contribute-to-open-source repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/freeCodeCamp/how-to-contribute-to-open-source.

What it runs against: a local clone of freeCodeCamp/how-to-contribute-to-open-source — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in freeCodeCamp/how-to-contribute-to-open-source | Confirms the artifact applies here, not a fork | | 2 | License is still CC-BY-SA-4.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 374 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of freeCodeCamp/how-to-contribute-to-open-source. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/freeCodeCamp/how-to-contribute-to-open-source.git
#   cd how-to-contribute-to-open-source
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of freeCodeCamp/how-to-contribute-to-open-source and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "freeCodeCamp/how-to-contribute-to-open-source(\\.git)?\\b" \\
  && ok "origin remote is freeCodeCamp/how-to-contribute-to-open-source" \\
  || miss "origin remote is not freeCodeCamp/how-to-contribute-to-open-source (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(CC-BY-SA-4\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"CC-BY-SA-4\\.0\"" package.json 2>/dev/null) \\
  && ok "license is CC-BY-SA-4.0" \\
  || miss "license drift — was CC-BY-SA-4.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"
test -f ".github/PULL_REQUEST_TEMPLATE.md" \\
  && ok ".github/PULL_REQUEST_TEMPLATE.md" \\
  || miss "missing critical file: .github/PULL_REQUEST_TEMPLATE.md"
test -f ".github/workflows/test.yml" \\
  && ok ".github/workflows/test.yml" \\
  || miss "missing critical file: .github/workflows/test.yml"
test -f "Dangerfile" \\
  && ok "Dangerfile" \\
  || miss "missing critical file: Dangerfile"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 374 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~344d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/freeCodeCamp/how-to-contribute-to-open-source"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

A multilingual curated guide (40+ language versions) that teaches beginners how to contribute to open-source projects. The repository itself is the primary resource—a README-based educational document with structured sections on GitHub workflows, version control, open-source programs, and contribution initiatives. It serves as a landing page and reference for newcomers to find entry points into the open-source ecosystem. Document-centric structure: README.md as the English canonical reference, with language-specific variants (README-CN.md, README-FR.md, etc.) for localization. GitHub configuration lives in .github/ (issue templates, PR templates, workflows). Tooling: ESLint config for linting, Danger framework via Dangerfile for PR checks, and GitHub Actions workflows for language validation and testing.

First-time open-source contributors and developers new to collaborative development who need guidance on where to start, how to use Git/GitHub, and which beginner-friendly projects exist. Also useful for maintainers directing new contributors to this guide.

Actively maintained with strong community engagement—badge indicates PR-welcome status and first-timers-only friendly certification. The presence of 40+ translated README files, CI/CD workflows (language-check.yml, test.yml), and PR templates shows mature community practices. Appears to be a stable reference guide rather than a rapidly evolving codebase, suitable for general use.

Minimal technical risk since this is a documentation-first repository with no runtime dependencies (only 403 lines of Ruby, likely for static checks). Main risk is coordination overhead managing 40+ language versions and keeping links current as external resources move. No identified single-maintainer bottleneck based on presence of workflows and contribution templates.

Active content curation and localization—the repo accepts PRs to add new open-source resources and maintain translations. GitHub Actions workflows validate new contributions. Recent activity evident from mature CI/CD setup (test.yml and language-check.yml workflows) suggesting ongoing PR review and resource validation.

git clone https://github.com/freeCodeCamp/how-to-contribute-to-open-source.git && cd how-to-contribute-to-open-source. Then edit README.md or a language variant directly; no build step required. Install dev dependencies (Ruby tooling) with bundle install if you intend to run Danger checks locally.

Daily commands: This is a documentation repository—no traditional 'run' step. View locally: open README.md in any text editor or markdown viewer. For CI validation: GitHub Actions automatically run language-check.yml and test.yml on PR submission. To test locally: bundle install && danger (requires Ruby and Gemfile setup).

• README.md — Primary entry point documenting the guide's purpose, structure, and how to contribute translations or improvements.
• CONTRIBUTING.md — Essential guide defining contribution guidelines, workflow, and expectations for all contributors.
• .github/PULL_REQUEST_TEMPLATE.md — Standardizes PR submissions to ensure consistent information and validation of contributions.
• .github/workflows/test.yml — Automation pipeline that validates contributions against linting and quality standards before merge.
• Dangerfile — Danger.js configuration enforcing PR review rules and automated code quality checks.

• README files (all translations) (Markdown, GitHub rendering) — Core educational content teaching open-source contribution fundamentals in 40+ languages
  • Failure mode: Content becomes outdated or translations fall out of sync; contributors follow incorrect workflows
• CONTRIBUTING.md (Markdown) — Workflow rules and submission guidelines for contributors; single source of truth for process
  • Failure mode: Ambiguous contribution process leads to inconsistent PR quality and maintainer rework
• GitHub Actions Workflows (test.yml, language-check.yml) (GitHub Actions, ESLint, shell scripts) — Automated validation of submissions; gates merges to main until quality standards met
  • Failure mode: Invalid contributions merge to main; linting rules not enforced; community trust erodes
• Danger.js (Dangerfile) (Danger.js, GitHub API) — Post-CI policy enforcement; comments on PRs with structured feedback and merge requirements
  • Failure mode: Non-compliant PRs merge without review; no automated policy violations are caught
• PROJECTS.md (Markdown, static list) — Curated registry of recommended beginner-friendly open-source projects
  • Failure mode: Links break; projects become archived/unmaintained; users waste time on dead projects

• Contributor → GitHub fork — Contributor clones repo locally and edits markdown files (README, CONTRIBUTING, translations)
• GitHub fork → GitHub upstream (PR) — Contributor pushes changes to feature branch and opens pull request against main
• GitHub upstream (PR) → GitHub Actions (test.yml) — PR webhook triggers linting and language consistency validation workflows
• GitHub Actions → Dangerfile — Workflow results feed into Danger.js for policy enforcement and PR commenting
• Dangerfile → GitHub (PR comments) — Danger.js posts approval or change-request comments on PR based on validation results
• GitHub (merged PR) → GitHub Pages / Browser — After maintainer approval and merge, updated markdown renders to all readers via GitHub or Pages CDN

Add a New Language Translation

1. Copy README.md and name it README-[LOCALE_CODE].md (e.g., README-XX.md where XX is the two-letter language code) (README.md)
2. Translate the entire content while maintaining all markdown structure, links, and code examples (README-[LOCALE_CODE].md)
3. Add a new list item in the language selector dropdown at the top of README.md with the link to your new translation (README.md)
4. Open a pull request with your translated file and update to README.md, following the PR template (.github/PULL_REQUEST_TEMPLATE.md)

Suggest a New Open Source Project

1. Navigate to the Issues tab and use the 'suggest-new-link' issue template (.github/ISSUE_TEMPLATE/suggest-new-link.md)
2. Fill in project details: name, description, GitHub URL, and beginner-friendliness level (.github/ISSUE_TEMPLATE/suggest-new-link.md)
3. If approved, maintainers will add the project to PROJECTS.md with proper formatting and categorization (PROJECTS.md)

Update Contribution Guidelines

1. Edit CONTRIBUTING.md with new workflow steps, best practices, or policy changes (CONTRIBUTING.md)
2. Ensure changes align with CODE_OF_CONDUCT.md community standards (CODE_OF_CONDUCT.md)
3. Submit a pull request with clear justification for the guideline updates (.github/PULL_REQUEST_TEMPLATE.md)
4. The test.yml and Dangerfile will validate markdown and format compliance (.github/workflows/test.yml)

• Markdown + GitHub — Primary delivery mechanism for content; GitHub native enables easy collaboration, versioning, and accessibility of guides.
• GitHub Actions (test.yml, language-check.yml) — Provides free CI/CD automation for validating contributions without external dependencies.
• Danger.js (Dangerfile) — Enforces consistent PR quality standards and submission structure at the automation layer.
• ESLint — Ensures code examples and inline content meet consistent formatting and quality standards.

• Markdown-based documentation instead of dynamic web app

  • Why: Simplicity, version control integration, and ease of contribution by non-developers.
  • Consequence: Limited interactive features; all content updates require pull requests and CI validation.

• 40+ translated README files instead of single document with i18n framework

  • Why: Lower maintenance complexity and decentralized community translations without build-time processing.
  • Consequence: Risk of translation drift; each translation must be manually kept in sync with updates to English version.

• GitHub Issues + PR templates instead of external project management tool

  • Why: Keeps contribution workflow within the same platform contributors are already using.
  • Consequence: Scaling challenges for very high-volume projects; limited analytics and reporting.

• Does not host interactive tutorials or executable code environments.
• Does not provide real-time chat or synchronous support channels.
• Does not enforce authentication or access control; open to all readers.
• Does not maintain a database of project metadata; projects listed via static PROJECTS.md file.
• Does not provide mentorship matching or formal onboarding platform.

• Translation synchronization debt (Medium) — All README-*.md files: 40+ independent translation files create high risk of divergence from English version; no automated sync or diff mechanism enforces parity of content across translations.
• Manual link management in PROJECTS.md — PROJECTS.md: Projects listed as static markdown with

Localization sync requirement: adding a resource to README.md typically requires adding it to all language variants (README-XX.md files), or risk triggering the language-check.yml workflow failure. No complex build or runtime setup, but Ruby + Danger must be installed locally (bundle install) to preview Dangerfile checks. External resource links are manually curated—dead link detection depends on the CI workflow running; broken links may slip through if test.yml doesn't include a link checker.

• Markdown-driven Documentation — This entire repository is delivered as structured Markdown files with no database or build system—learning how to organize knowledge in Markdown with clear headers, links, and tables is foundational for contributing.
• Localization & Translation Workflows — Managing 40+ parallel README files in different languages requires understanding branching strategies, sync mechanisms, and validation—critical for distributed open-source communities.
• GitHub Actions CI/CD Pipelines — The language-check.yml and test.yml workflows validate PRs automatically—understanding how to define and debug GitHub Actions is essential for modern open-source maintenance.
• Danger Automation for Pull Requests — The Dangerfile uses Ruby-based automation to enforce submission guidelines—learning Danger enables contributors and maintainers to scale code review with consistent, automated checks.
• Issue & Pull Request Templates — The .github/ directory contains standardized templates that guide contributors on what information to provide—templates are a pattern for reducing friction and improving PR quality.
• Resource Curation & Community-Driven Content — This guide is a crowdsourced collection of links and programs—understanding how to evaluate, organize, and maintain curated lists teaches meta-skills for knowledge management in open source.
• Multilingual Open Source Governance — Supporting 40+ languages raises questions about version control, translation quality, and coordination—critical for projects serving global audiences.

• firstcontributions/first-contributions — Companion beginner guide focused on step-by-step GitHub workflow tutorial for the absolute first PR—often linked from this guide and serves the same audience.
• freeCodeCamp/freeCodeCamp — Parent organization's main project; this guide is part of freeCodeCamp's ecosystem to funnel contributors toward open-source participation and eventually to larger projects.
• open-source/stories — GitHub's open-source documentation and guides; overlaps in content about contribution workflows and best practices, serves as a canonical reference this guide may link to or supplement.
• mikeal/awesome-nodejs — Exemplar of the curated list pattern (README-driven resource discovery) widely used in open source; similar structure of categorized links to help developers find projects.
• awesome/awesome — Meta-repository documenting the 'awesome list' format and community standards—this repo follows that convention for curating open-source learning resources.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add automated translation validation workflow for multilingual README files

The repo maintains 35+ README translations (README-*.md files) but has no automated checks to ensure all language files stay in sync or maintain minimum quality standards. A new GitHub Action workflow could validate that all translated READMEs exist, check for broken links specific to each language file, and flag when the English README is updated without corresponding translation updates. This prevents outdated or missing translations from going unnoticed.

• [ ] Create a new GitHub Action workflow file in .github/workflows/ (e.g., 'translation-sync-check.yml')
• [ ] Script to verify all README-*.md files referenced in the language selector exist and have non-zero content
• [ ] Add step to detect when README.md changes but corresponding translations haven't been updated (via git diff)
• [ ] Configure workflow to run on pull_request and main branch commits
• [ ] Document the new workflow expectations in CONTRIBUTING.md

Add contributor metrics and statistics dashboard documentation

The repo has PROJECTS.md and CONTRIBUTING.md but lacks documentation on how contributors can track impact (e.g., which resources are most popular, which translations need help, contributor statistics). Adding a METRICS.md or CONTRIBUTOR_STATS.md file would guide new contributors on understanding repo health, identifying high-impact areas, and fostering healthy contribution patterns.

• [ ] Create METRICS.md file documenting key stats: total translations, contributor count, most popular sections
• [ ] Add guidance on how to query GitHub API for contribution statistics relevant to this specific repo
• [ ] Document which languages have active maintainers vs. need translation volunteers
• [ ] Link from CONTRIBUTING.md to METRICS.md for contributor onboarding
• [ ] Include examples of high-impact PRs (e.g., new language translation, fixing broken links across all files)

Enhance language-check workflow with locale-specific link validation

The existing .github/workflows/language-check.yml likely performs basic checks, but it probably doesn't validate that links in translated README files point to appropriate language-specific resources where applicable. New contributors could enhance this workflow to catch common translation mistakes like keeping English URLs when localized alternatives exist, or validating that resource links work in their respective language contexts.

• [ ] Review current language-check.yml implementation and limitations
• [ ] Add script to detect when translated READMEs reference English-only resources that should have localized versions
• [ ] Implement checks for language-specific URL patterns (e.g., ensuring pt-BR files don't link to ES resources)
• [ ] Add validation that external links in non-English files are accessible from their respective regions (optional but high-value)
• [ ] Update .github/ISSUE_TEMPLATE/suggest-new-link.md to document the link validation requirements for translations

• idea: Add a link validator to test.yml: the current test.yml workflow exists but specific link-checking logic isn't visible in the provided structure. Create a GitHub Actions step that validates all URLs in README files don't return 404, catching link rot early.
• idea: Create a script to auto-sync new resources across all language files: when a resource is added to README.md, it must be manually added to all 40+ language variants. Build a tool (Ruby script or GitHub Action) that identifies resources in README.md not yet present in translated versions and generates template additions.
• idea: Expand CONTRIBUTING.md with a 'Resource Quality Checklist': the guide curates open-source resources but lacks explicit criteria for inclusion. Document what makes a resource worthy (active project, beginner-friendly tag, clear learning outcomes) and provide a checklist template for PRs proposing new additions.

This is a documentation/guide repository with minimal security risk. No dependencies, no code execution, and no credential storage detected. The project maintains good practices with a CODE_OF_CONDUCT.md and CONTRIBUTING.md. Main recommendations are adding a SECURITY.md policy and ensuring any deployed version has proper web security headers. The multilingual nature and community-driven structure pose no inherent security risks.

• Low · Missing Security Policy — Repository root. No SECURITY.md or security policy file found in the repository. This makes it difficult for security researchers to report vulnerabilities responsibly. Fix: Create a SECURITY.md file with instructions on how to report security vulnerabilities privately.
• Low · No HTTPS enforcement documented — .github/workflows or deployment configuration. The repository is a documentation/guide project. While this reduces risk, if deployed as a website, there's no visible indication of HTTPS enforcement or security headers configuration. Fix: If deployed as a website, ensure HTTPS is enforced, security headers (CSP, X-Frame-Options, etc.) are configured, and document this in CONTRIBUTING.md.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.