Don't Open a Pull Request Yet

Source: Dev.to

Why contributions matter

You want to contribute to open source, but you don’t want to be that person:

• the one who opens a pointless pull request just to add their name to a README.md.
• the one who pastes AI‑generated code, wraps it in a polished PR description, and assumes “looks right” means “is right”.
• the one who leaves a maintainer with more work than before they saw your name in the notifications.

That fear is healthy, because the uncomfortable truth is this: a lot of visible contribution is not useful contribution.

A maintainer is rarely asking, “Did this person submit something?”
They are asking three quieter questions:

1. Is this needed?
2. Is this correct?
3. Is this easy to trust?

Most weak contributions fail on one of those points before the code itself even matters.

---

Good contributions start before the pull request

Start with context, not a PR

People love to say, “Just find an issue and start.”
That is fine advice if your goal is activity, but it is bad advice if your goal is usefulness.

A repository is not a bucket of chores waiting for strangers. It is a living system with:

• trade‑offs,
• history,
• backlog pressure, and
• people trying to keep it moving.

If you open a pull request before you understand any of that, you are not really helping yet—you are asking someone else to assess your judgment.

Tiny, visible changes can still be poor contributions

A one‑line diff is not automatically a one‑minute ask. Someone still has to:

• read it,
• place it in context,
• decide whether it belongs, and
• often explain why it does not.

The “add your name to the README” wave made that painfully clear. In February 2024, Express contributors were openly discussing how to curb spammy README.md pull requests from new contributors because they were creating noise and extra moderation work rather than meaningful progress.

---

A better test than “Can I open a PR?”

Ask yourself instead:

• Does this change solve a real problem the project actually has?
• Can I explain why this approach makes sense here?
• Have I made it easy for someone else to trust what I’m proposing?

If the answer is not yet “yes”, you probably need more context, not more code.

---

The social architecture of a project

Open‑source projects have technical and social architecture.
Usually there is a pattern to:

• how decisions get made,
• how questions get answered,
• what gets prioritised, and
• what gets pushed back on.

If you miss that layer, you can write a technically decent patch and still make a poor contribution.

Where to start

1. Read the obvious documents, but treat them as operating instructions rather than admin clutter:

   • README
   • Contribution guide
   • Issue templates
   • Pull‑request template
   • Code of conduct
   • Governance notes

   These pages tell you what kind of help the project wants, where different kinds of discussion belong, and what behaviour creates friction.

2. Study the project in motion:

   • Read a few open issues from start to finish.
   • Read a few recently merged pull requests.
   • Read a few that were closed without merging.

   That comparison is often more useful than any generic open‑source advice because it shows you how this project behaves in practice.

You will start to notice patterns, e.g.:

• Small, scoped changes land faster than broad clean‑ups.
• Maintainers care a lot about tests.
• Larger changes need discussion before implementation.
• Support questions belong somewhere else entirely.
• The project values consistency more than cleverness.

That is the social architecture—it tells you what “helpful” means here, not in theory.

---

How to ask good questions

• A weak question hands your confusion to someone else.
  Example: “Can someone explain this whole module?”

• A strong question shows the thinking you have already done.
  Example: “I traced this behaviour to foo.js, and I think the bar branch is why the bug appears, but I’m not sure whether that behaviour is intentional.”

The second question gives someone something concrete to respond to. It narrows uncertainty instead of exporting it. That is the habit you want.

---

Understanding project pressure points

From the outside, an open‑source project can look like a simple list of issues and pull requests. From the inside, it is usually a bundle of maintenance costs competing for limited attention:

• Bugs need reproducing.
• Pull requests need review.
• Regressions need testing.
• Releases need preparing.
• Duplicate reports need closing.
• Docs need updating.

That is why project behaviour can look harsher than it really is:

• A slow reply is not always dismissive.
• A short reply is not always rude.
• A closed issue is not always a judgment on you—it may simply mean the project is protecting scarce attention.

Find where the pressure actually is

• If the issue tracker is full of vague reports, a careful reproduction is useful.
• If pull requests keep stalling on tests, test work is useful.
• If the same confusion keeps appearing in issues, a precise docs fix is useful.
• If maintainers keep redirecting people to the same answer, someone who reads first is already easier to work with.

Many contributors choose work that looks like contribution instead of work that relieves pressure. Maintainers do not need more contribution‑shaped activity; they need fewer unknowns, fewer unnecessary reviews, and fewer loose ends.

---

Getting started without total understanding

A lot of new contributors open a repository and try to understand the whole thing. That is usually wasted effort.

You do not need total understanding. You need enough local understanding to make a trustworthy change.

The best way to get that is to read the codebase like an investigator, not a tourist. Start from a concrete question, gather the surrounding context, and only then propose a change that answers the three key questions above.

Navigating a Codebase Efficiently

1. Follow the path the question takes through the system

   • Bug – start where the bug appears and trace inward.
   • Feature – start where the user encounters it and follow the flow.
   • Error message – search for the exact text and locate its origin.

   This is far more effective than browsing files until something feels familiar.

2. Look for landmarks

   • Where is the setup logic?
   • Where are the tests?
   • Which modules appear repeatedly in recent pull requests?
   • Are there architecture notes?
   • Are there directories whose names keep coming up in issue discussions?

   Those clues point you toward the important paths.

3. Leverage the test suite

   • Tests define what the project considers “correct.”
   • They show how contributors are expected to express changes.
   • When you want to understand a piece of behaviour, the tests often explain it more clearly than the implementation.

4. Study recent pull requests

   • Find a recent change in the same part of the codebase.
   • Read the diff, then read the review comments.
   • You’ll often learn more from what had to be clarified, shrunk, or re‑worked than from the final code alone.

Goal: Don’t read widely; become specific.
When you can say, “The bug starts here, flows through these two modules, and is probably covered by this test,” you’re in a much better position to contribute—not because you know the whole codebase, but because you know the part you’re touching well enough to make your reasoning visible.

---

Using AI Responsibly in Open‑Source Contributions

AI is now part of open‑source contribution whether people like it or not. The real question isn’t whether you use it, but how you use it.

A simple rule cuts through most of the noise

Use AI to compress learning. Do not use it to compress responsibility.

• Good uses of AI

  • Understanding a pattern.
  • Comparing approaches.
  • Summarising documentation.
  • Suggesting test cases.
  • Helping you phrase a question more clearly before you post it.

  CPython’s contributor guide permits these uses while reminding contributors that they remain responsible for the usefulness and quality of what they submit. Maintainers may close issues and PRs that are not useful or productive, including ones that are fully generated by AI.

• What AI should not do

  • Become your proxy.
  • Automatically generate normal project communication (issue descriptions, PR descriptions, comments).

Policy examples

Why this matters: Maintainers review for fit, not just for local plausibility.

Checklist before submitting AI‑generated work

1. Does this solve the real problem?
2. Does it match the project’s conventions?
3. Does it introduce churn for little benefit?
4. Can the author explain why this approach makes sense here?

Plausible‑looking code is not the same as a good contribution. If you would struggle to answer “Why this change?” in a review, AI has not saved you time—it has merely delayed the cost until someone else pays it.

---

Choosing a First Contribution

Once you have context, understand the project’s pressure points, and know your way around the relevant code, you don’t need to start with a grand fix. Begin with contributions that remove ambiguity—the biggest drain on maintainers.

Typical low‑friction first contributions

• A bug report with exact reproduction steps.
• A focused test that proves a failure clearly.
• A docs fix that removes a common point of confusion.
• A small patch in an area you have already traced properly and can explain with confidence.
• A careful confirmation that an issue still exists in the current version.

What matters: Not whether the change is glamorous, but whether the thinking is legible.

This is a better filter than “good first issue,” which can hide the real question. The real question isn’t “Is this easy?” but “Can I understand this fully enough to make a change that is needed, correct, and easy to trust?”

---

The Bigger Picture

Good open‑source contribution starts earlier than code:

1. Learn how the project makes decisions.
2. Identify where it is under pressure.
3. Focus on work that reduces uncertainty rather than adding more.
4. Read the codebase with a concrete question in mind.
5. Use AI, if at all, as a tool for understanding instead of a way to outsource judgment.

The standard worth aiming for

• Not “I opened a pull request.”
• Not “I got something merged.”
• But: I made this project easier to work on.

That is what maintainers notice, what builds trust, and what turns you from a name in the notifications into someone the project is genuinely glad to see.