Rust issue trackers speak two dialects. rustc-style and a lot of crates tag work E-easy and E-help-wanted. GitHub’s beginner string is good first issue (plus help wanted). They are not synonyms. GitHub search is exact. If you only query one family, you miss a pile of real first tickets.

The live list on this site is GitHub labels. Start there. After you land on a repo, look at its labels: some crates keep the E-* scheme on GitHub, some only on another tracker the issue will name. Hunt both. Do not wait for a crate to rename its tags.

The generic hunt is how to find good first issues. Multi-language picking is best open source projects for beginners. This page is only what “first” means when the language is Rust.

The Rust hub is GitHub labels

Rust hub

That feed is labeled good-first and help-wanted issues from active GitHub projects whose language is Rust. On 2026-08-31 it showed about 2,801 labeled issues at 10+ stars. Snapshot only. The count moves.

E-easy does not magically appear in that list. The hub indexes GitHub’s label strings. Use it to find a living repo, then read the label set on that repo. If the ticket lives on a non-GitHub tracker, follow the link in the issue. The hub will not invent it.

If you do not write Rust, use the homepage and pick the language you do.

Read the body, not the title. Skip stale threads, claimed threads, and repos that have not merged pull requests lately. After you have a candidate, run the checks in how to pick an issue that will get merged.

I am not listing crates. A leftover label on a well-known name is still leftover.

One failing doctest is a first PR

docs.rs is compiled rustdoc. The source is ///, //!, and sometimes examples/. A ticket that says “the docs.rs snippet panics” is asking you to fix the comment so cargo test --doc is green. It is not asking for a book.

Shapes that merge:

A rustdoc example block that stopped compiling
A # Examples section the issue already wrote in the thread
One failing doctest on a public item
An examples/ binary the README still names

Done is: cargo test --doc passes for that item, or cargo run --example … / the crate’s usual test command builds the named example. Done is not a new mdBook, a theme, or a rewrite of the crate-level //! because you would have ordered modules differently.

Match their loop. CONTRIBUTING often names cargo test --doc, cargo test --all-features, or a specific example. Run that on the default branch before you edit. If you cannot get doctests running, pick another issue. Debugging their rustdoc harness is a second project.

Hidden doctest lines (# let x = …) exist so the snippet on docs.rs stays short while the test still compiles. Copy the project’s existing examples. Do not “simplify” by deleting the # setup and then “fix” three other pages.

A rustdoc-only merge counts. An unasked guide does not.

Clippy is opt-in; rustfmt is a hunk, not a crate

cargo clippy will always have opinions. That is not an invitation.

A first-time clippy --fix rewrites call sites nobody asked you to touch. Maintainers read it as a lint crusade. They close it, or they make you revert 90% of the diff, which is the same delay.

Same trap with rustfmt: formatting a 2,000-line file because the editor offered to turns a one-line rustdoc fix into a merge conflict against every open PR.

Rules:

Edit clippy.toml, [lints.clippy], or #![warn(clippy::…)] only when that lint is the issue
Do not enable a nursery lint you like locally
Do not mix a doctest with a Clippy pass
rustfmt the lines you wrote. If CI runs cargo fmt on the whole crate, let CI. If CONTRIBUTING says run cargo fmt before push, run it — then revert files the issue did not name if fmt rewrote them
Pre-existing Clippy warnings on lines you did not need stay

Tool config is policy. Policy is not issue one unless the ticket is the tool.

Compiler, runtime, and unsafe are issue two

Skip compiler internals, runtime guts, and unsafe core on purpose. Borrow-checker edges, allocator hooks, FFI boundaries, Send/Sync impls, unsafe blocks that hold an invariant the rest of the crate trusts — those review like architecture. An E-easy or good first issue badge on them is a request for help, not a size.

Your first merge should be a leaf: the doctest, the example, a safe public function the ticket named, a unit test around that function.

unsafe is not a difficulty badge. It is a promise. Do not take it to look more serious while a failing docs.rs example is sitting open.

After you have a merge in that repo and have watched how they review unsafe, issue two can move inward. Not before.

Cargo.toml is not a souvenir

Touch Cargo.toml, features, MSRV, or [lints] only if the issue asked. Feature flags and MSRV review as policy. A doctest that also “tidies” features is two reviews; the second one stalls the first. Leave edition and MSRV bumps for a ticket that is those bumps.

Tonight

Filter on the Rust hub. That is GitHub labels. On the repo, also look for E-easy / E-help-wanted if they use that scheme. Drop stale and claimed threads. Confirm recent merged PRs.
Read CONTRIBUTING.md for cargo test, doctests, and fmt. Get the default branch green before you edit.
Comment on one issue. Do not reserve five.
Keep the diff on the ticket. No Clippy drive-by. rustfmt only what you touched. Link Fixes #123. Say how you ran cargo test --doc or the example. Stay for review.

Git mechanics: first pull request guide. Week-1 map: how to contribute to open source.

FAQ

Why do some Rust issues say E-easy instead of good first issue?

rustc-style and many crate trackers never switched to GitHub’s string. E-easy / E-help-wanted mean effort and extra hands. good first issue is GitHub’s beginner label. Search both. The Rust hub indexes GitHub labels, not every E-* tag on a different tracker.

Is a docs.rs or rustdoc change a real first Rust PR?

Yes. One failing doctest, a rustdoc fence that compiles again, or an examples/ file the ticket named is a real merge. A volunteer rewrite of the crate-level docs is not. Do the ticket.

Can I run cargo clippy —fix while I am in the repo?

Only if the issue asked. Clippy diffs are policy. They bury a doctest and often get the whole PR closed. Leave clippy.toml and [lints.clippy] alone unless that file is the ticket. rustfmt only the lines you touched.

Can my first issue be in the compiler, the runtime, or unsafe?

No. Leave compiler internals, runtime guts, and unsafe core until issue two. Those files have implicit contracts. Issue one is a leaf: rustdoc, an example, a safe public function, a unit test.

Where do I find live Rust good first issues?

On the Rust hub. Filter GitHub-labeled work, then check the repo for E-easy if they use that scheme. Skip stale and claimed threads. Read CONTRIBUTING for cargo and doctests. Other languages: the homepage.

Start here

Open the Rust hub. Pick one unclaimed ticket that is a rustdoc example, a failing doctest, or a leaf safe function. Hunt E-easy on the repo if they use it. Comment once, leave Clippy alone, rustfmt only what you touched, keep the diff on that job, and stay for review. Not writing Rust tonight? The homepage is the language switch.