This URL is you can land a specified issue without understanding the whole architecture. Docs, one function, one fixture, one UI string. Bound the read. Ship that slice.

It is not how to find and run the test command. That is how to run tests in an unfamiliar repo. It is not picking a labeled test or coverage ticket as your first merge. That is tests as a first contribution. It is not writing the issue.

Unfamiliar is normal. The issue is the map. If the issue does not name a file, a string, or a function, it is not a first patch. Pick another.

The issue is the map

A specified issue points at a hole you can hold:

docs/install.md still shows the old flag.
The empty-state string in the settings panel is wrong.
parseConfig panics when the file exists but has no keys.
The fixture for the 404 HTML page is missing a charset meta.

Those tickets do not require a tour of the auth service, the queue, or the deploy graph. They require the file they named, plus whatever that file already imports.

Hunt specified issues on Help Wanted and the language hubs: Python, TypeScript, JavaScript. How to pick an issue that will get merged is the filter. This page is what you refuse to read after you picked.

Bound the read

Set a budget. Thirty minutes of reading before you write. If you cannot see the hole in that time, the issue was not specified, or you picked the wrong surface.

Start at the path in the ticket. Open that file. Search the string, the function name, or the heading they quoted.

Read the function, not the package. If parseConfig is fifty lines, read those fifty. Do not read the caller graph until the function itself is unclear.

Follow one import. If the function calls decode, open decode. Stop at the second hop unless the issue names it.

Use the tests as examples, not as a syllabus. One neighboring case shows how they construct input. You are not here to learn the suite. Finding the runner is the other page.

Search, do not browse. Repository search for the flag, the UI string, the error text. The file tree is a trap. src/ can be huge. The ticket is a needle.

Four slices that do not need the architecture

One docs hole. The ticket names a page and a wrong fact. Fix that fact. Documentation as a first contribution is the docs-shaped version of this. Do not reread the product to rewrite Getting Started.

One function. The ticket names parseConfig and the empty-file panic. Change the return. Leave the rest of the config package alone.

One fixture. The ticket names a JSON or HTML file under testdata or fixtures. Edit that file, or add the one they described. Do not regenerate every snapshot.

One UI string. The ticket quotes the copy. Change the string, or the i18n key if that is how they store copy. Do not restyle the panel.

If your change needs a new module, a new dependency, or a new pattern, you left the slice. Comment on the issue instead of inventing architecture.

When to stop reading

Stop when you can describe the change in one sentence that matches the issue. Stop when the next file you would open is a framework intern. Stop when you are reading git history for fun.

Do not stop if the named file is generated and the source lives elsewhere (i18n catalogs, codegen). Follow that one hop.

Do not stop if CONTRIBUTING names a branch, a DCO, or a CLA. Those are process, not architecture. Extract them from contribution guidelines and move on.

What you still owe the project

A specified slice is not a free pass to skip their process. Claim the issue if they ask. Fill the PR template. Link Closes. Put how you checked the change in the PR description.

You do not owe a design doc. You do not owe a tour of similar bugs. You do not owe a second feature you noticed while grepping.

How to run tests in an unfamiliar repo — the command, not the architecture
Tests as a first contribution — when the specified issue is a missing case
Documentation as a first contribution — when the slice is docs
How to pick an issue that will get merged — specified vs wishlist
How to claim a GitHub issue — the comment
Non-code open source contributions — when the slice is not code

FAQ

Do I have to understand the whole repo before my first PR?

No. You have to understand the named hole. Architecture comes later, if you stay.

The issue has no path. Can I still use this page?

Search for the quoted string. If nothing matches, ask for a file on the ticket. If nobody points at one, pick another issue.

I found a second bug while grepping. Add it?

No. File it or comment. This PR stays the specified slice.

Is this the same as a test-first contribution?

No. A test issue is one kind of slice. This page is any specified hole, including copy and docs, without mapping the system.

Do I skip tests because I barely read the tree?

No. Run what they ask on the files you touched. How to find that command is the other page.

Good vs bad

Bad. Clone, read every package README, sketch the architecture, then change a string. Three days, no PR.

Good. Issue quotes the empty-state copy. Search finds the i18n key. Change the string. Open the PR that afternoon. You still do not know how billing works. You do not need to.