Esc
↑↓ navigate   Enter open   Esc close
Beginner Reading #open-source #contributing #github #pull-requests

🤝 Reading: Open-Source Contribution Guides

3 exercises — read a realistic CONTRIBUTING.md file. Understand when to open issues, how to reference them in PRs, and how to write Conventional Commit messages.

CONTRIBUTING.md — what to look for
  • Ways to contribute → not just code — bug reports, docs, and reviews count
  • Before You Start → process to follow before writing code
  • PR Guidelines → what reviewers expect: tests, focused scope, issue reference
  • Commit format → feat:, fix:, chore:, docs:
  • Open an issue first for big changes — save everyone's time
0 / 3 completed
1 / 3
🤝 CONTRIBUTING.md (based on Astro) 
# Contributing to Astro

Thank you for your interest in contributing! This guide explains how to get
started, what types of contributions we welcome, and what to expect from
the review process.

## Code of Conduct

This project follows the Contributor Covenant Code of Conduct. By participating,
you agree to uphold this code. Please report unacceptable behavior to
conduct@astro.build.

## Ways to Contribute

We welcome many forms of contribution — you don't have to write code to help!

- **Bug reports**: Open an issue describing what you expected vs. what actually happened.
  Use the Bug Report template. Include steps to reproduce.
- **Feature requests**: Open an issue with the Feature Request template.
  Describe the use case, not just the implementation.
- **Documentation**: Fix typos, clarify unclear sections, add missing examples.
- **Code**: Fix bugs, implement features. See "Development Setup" below.

## Before You Start Coding

1. **Search existing issues** — your bug or feature may already be tracked.
2. **For significant changes**, open an issue first and wait for maintainer
   feedback before investing time in implementation. This prevents duplicate
   work and ensures the change aligns with the project's direction.
3. **For small fixes** (typos, broken links, 1-3 line bug fixes), a PR is fine
   without prior issue discussion.

## Development Setup

```bash
# Fork the repo on GitHub, then clone your fork
git clone https://github.com/YOUR_USERNAME/astro.git
cd astro
pnpm install        # uses pnpm workspaces
pnpm run build      # build all packages
pnpm run test       # run the test suite
```

## Pull Request Guidelines

- Keep PRs focused: one feature or one bug fix per PR.
- Reference the issue your PR addresses: "Fixes #1234" in the PR description.
- All tests must pass. Add tests for new behavior.
- Update documentation if your change affects the public API.
- Expect at least one review cycle. Reviewers may request changes.
- Do not push to a shared branch directly — always branch off main.

## Commit Message Format

We use Conventional Commits:
  feat: add support for custom 404 pages
  fix: resolve hydration mismatch in SSR mode
  docs: update installation guide for Windows
  chore: upgrade esbuild to v0.19

The type prefix tells maintainers what kind of change it is without
reading the full diff.
According to the guide, when should you open an issue BEFORE submitting a pull request?