13 - Picking a Project¶

What this session is¶

About 30 minutes plus your browsing. What makes a Rust project a good first target, plus a list of real candidates.

Why the wrong project burns you out¶

Common path: 1. Pick something you use (Tokio, say, or Diesel). 2. Three hours setting up the dev environment. 3. Find a "good first issue" untouched for months. 4. Two weeks understanding enough to make a change. 5. Submit PR. 6. Three weeks of silence; then "please rebase and address these 15 comments." 7. Quit.

Fix: pick small, responsive projects first.

"Manageable" criteria¶

Small enough to comprehend. Under 10k LOC of Rust is ideal. Under 50k is doable.
Active maintainers. PRs reviewed in days, not weeks.
good first issue / help wanted labels.
CONTRIBUTING.md exists and is readable.
cargo test passes on fresh clone.
You care or are curious about what it does.

10-minute evaluation¶

Signal	What you want
Stars	100 - 50000
Last commit	Within a month
Open PRs	Some, not 200+
Recent PR merge time	Under 14 days
`good first issue` count	At least 5
`CONTRIBUTING.md`	Yes, readable
CI green on main	Yes
Code of conduct	Yes

Candidates (verify state before committing)¶

Tier 1 - very small, very gentle¶

seanmonstar/num_cpus - tiny one-function crate. Almost any contribution is welcomed.
Dirkjan/ical-rs - calendar parser. Small surface area.
bluss/scopeguard - tiny utility.
assert-rs/assert_cmd - small test-helper crate; maintainers responsive.

Tier 2 - small to medium¶

clap-rs/clap - the CLI parser. Big project but excellent labels and very welcoming.
uutils/coreutils - Rust reimplementation of GNU coreutils (ls, cat, etc.). Each utility is small; great labeled issues.
ratatui-org/ratatui - terminal UI library. Active and welcoming.
mockito-rs/mockito - HTTP mocking library.
fdehau/tui-rs - predecessor to ratatui; still maintained.
serde-rs/serde - the serialization framework. Big but with very labeled work.

Tier 3 - larger, more visible¶

After 1-2 Tier 1-2 contributions:

BurntSushi/ripgrep - fast grep. Substantial; well-organized.
alacritty/alacritty - terminal emulator. C-level work in places.
tokio-rs/tokio - async runtime. Huge; very welcoming.
rust-lang/cargo - Cargo itself. Long review times but very respected to contribute to.

Tier 4 - massive, don't start here¶

rust-lang/rust - the language itself. CLA required (you sign Rust's CLA on first PR). Slow review. Some areas are fine for first contribution (docs, error messages); most isn't.

Finding issues¶

Project's Issues tab → Labels. Filter by: - good first issue / E-easy / easy (varies by project) - help wanted - documentation

Look for: clear description, contained fix, unclaimed, not open for a year.

Comment: "I'd like to take this. Can you confirm it's still wanted?" Wait for response.

What counts as a contribution¶

Small things absolutely count: - Fix a typo in README or docs. - Improve a doc comment. - Add a doctest. - Improve an error message. - Add a missing #[derive(Debug)]. - Small bug with clear repro.

First PR's job: get you through the workflow.

Exercise¶

Browse three Tier 1-2 projects. Run the 10-minute eval. Take notes.
Pick the most responsive.
Read its CONTRIBUTING.md.

Clone:

git clone https://github.com/<owner>/<repo>
cd <repo>
cargo test

If tests don't pass on fresh clone, consider another.

Browse good first issue tickets; pick two candidates. Don't claim yet.

What you might wonder¶

"What if a project requires a CLA?" Big projects (Rust itself, Mozilla projects) require signing one. Usually a one-time click via a bot. Don't let it stop you.

"What if I find a bug but no issue?" File one first. Describe, wait for ack, then offer to fix.

Done¶

Articulate what makes a Rust project a good first target.
Run a 10-minute eval.
Find appropriately-sized issues.
Avoid common traps.

Next: Anatomy of a Rust OSS repo →