Contributing to Open Source in the AI Era Without Burdening Maintainers: A Four-Week Plan

For anyone who wants to try contributing to an open source project, including beginners and heavy AI users. You do not need to know a community's process beforehand. Every term comes with an everyday picture, and the git walkthrough is marked so you can skip it if you do not need it yet.

Figures come from public sources, listed at the end. Examples labelled "illustration" are made up and name no real person or project. This post does not tell a personal contribution story, because I have none to tell. The git walkthrough is something I really ran on a practice repository on my machine. Nobody fully understands how AI models work inside, so the pictures below are memory aids only.

---

Quick summary#

• Maintainers of open source projects are receiving many low-quality contributions generated by AI. A Linux Foundation Research survey (20 October 2026) reports that maintainers estimate about 25% of pull requests are "AI slop", and 31% on large projects.
• One concrete example: curl ended its bug bounty at the end of January 2026. Its lead maintainer wrote that the share of security reports that turned out real fell from above 15% to below 5%.
• The way to avoid burdening them fits in four weeks: week 1 read and use the project, week 2 pick a small accepted issue and ask first, week 3 make a small tested change you can explain without AI, week 4 open a clear pull request, disclose AI and take feedback calmly.
• Every project has its own rules and they change fast. Some allow AI if you disclose it and understand it, some ban it. You must read the rules of the project you are contributing to, not rely on this post.
• In the git walkthrough I really ran (Git 2.56.0), one small change goes through three steps: test first, fix second, then amend after feedback. My first run also said "NO TESTS RAN", a good reason to always note how many tests ran.
• Rejection is normal. The goal of the four weeks is not to get merged at any cost, but to behave so that next time someone wants to read your work.

---

Hard words, plain meaning#

---

After this post you can explain#

1. Why open source maintainers dislike unchecked AI-generated contributions, and why projects' policies can differ completely.
2. The four-week order: read the rules, ask first, make a small tested change you understand line by line, then open the PR and disclose AI.
3. The git flow for this: your own branch, a commit with a test, a rebase when the project has moved on, and an amend after feedback.

---

1. A picture first: you are a guest in someone else's workshop#

Picture a small carpentry workshop run by one owner who lets visitors drop in. One visitor walks in and says, "I think this place could look nicer", then brings a cartload of things they made and puts them in three or four corners. Maybe the things are good. But the owner has to inspect every piece, make room, and if something breaks it is the owner who answers for it. Another visitor sits and watches for a week, asks, "May I sand that chair for you?", sands exactly one chair and brings it over to be looked at. The owner will remember the second name.

Open source is the same. Maintainers are often people working in their spare time or unpaid. Every pull request is a piece they have to check. AI makes sending a piece far cheaper, but checking it still costs the maintainer's time.

Takeaway: good contribution is not measured by how many lines you send but by how easy you make it for the maintainer to say yes.

---

2. Why maintainers are overwhelmed#

2.1 The Linux Foundation Research survey (20 October 2026)#

Linux Foundation Research published the report "Navigating Open Source Software Development in the Generative AI Era: Challenges and Opportunities for Project Communities" on 20 October 2026. According to their press release, maintainers estimate about 25% of incoming pull requests are AI slop, and 31% on large projects. The same release says 59% of maintainers see growing contribution volume (69% on large projects), about 35% of projects have a formal policy that permits AI, 32% have no policy and no plan for one, and 61% of contributors say they review and fully test AI-generated code before submitting it. It also reports respondents estimating an average of about 52% less time to write code.

Read this carefully. These are estimates by survey respondents, not a count of pull requests. The press release I read does not state how many people answered. I read the press release, not the full report. The sample may lean toward people willing to answer a survey.

Takeaway: the problem is real and measured, but most projects have no clear rule yet. You have to go and find the rule.

2.2 One project as an example: curl ends its bug bounty#

Daniel Stenberg, curl's lead maintainer, wrote in "The end of the curl bug-bounty" on 26 January 2026 that curl no longer has a bug bounty, effective 31 January 2026. He states that before 2025 the share of submissions confirmed as real vulnerabilities was "north of 15%", and since 2025 it is "below 5%", not even one in twenty. He names AI slop, low-quality human reports and a bad faith attitude from some reporters as reasons, and he suspects the cash rewards attracted that abuse. He also says people who submit AI slop continue to be banned.

This describes one project and the view of someone inside it. It does not prove every project is the same, and cash rewards may be specific to curl.

Takeaway: when the receiver is flooded, they close doors. When a door closes, good contributors suffer too.

2.3 GitHub gives maintainers more controls#

On 13 February 2026 GitHub added two repository settings: turn pull requests off entirely, or let only people with write access open new pull requests (everyone can still read and comment). They sit under Settings, General, Features. A Japanese developer blog I found reported that someone tested the "collaborators only" setting and saw it behave differently from the description at the time, so treat this as something that may have changed. GitHub is also reported to have added a cap on how many pull requests a user without write access can have open at once (June 2026, which I only saw in news coverage).

Takeaway: some repositories will not accept pull requests from strangers. First, find out whether the one you want does.

2.4 A real policy: Ghostty#

To see how specific a policy can get, I read the CONTRIBUTING.md and AI_POLICY.md files of the Ghostty project. I state only what I read at the time of reading, and the policy may have changed by the time you read this. According to those files: the project allows AI to write code, but requires disclosure of all AI use (naming the tool and the extent), requires contributors to understand all the code they submit and explain it without AI, and requires first-time contributors to be vouched for, otherwise pull requests are closed automatically. The project also keeps a public list of people turned away for submitting low-quality contributions. The rules apply to outside contributors, not maintainers.

This is one project. Another may be looser, or ban AI-generated contributions outright. This post relies on no project beyond the ones read above.

Takeaway: the rules live in the project itself. The first question is not "what do I do" but "what do they say here".

---

3. The four-week plan#

Picture four visits to the workshop: the first to look, the second to ask, the third to work, the fourth to hand something over. The time below is a suggestion, a few hours a week.

Week 1. Read and use the project#

Do:

1. Pick a project you actually use. If you do not use it, it is hard to know what would help.
2. Read the README, CONTRIBUTING, CODE_OF_CONDUCT and, if there is one, the AI policy. Find out whether the project takes pull requests from strangers at all.
3. Read about five accepted pull requests and five closed ones. Notice how people write descriptions and why things get closed.
4. Install and run the project on your machine, and run its test suite once.

Take away: five lines of "house rules of this project" in your own words, plus the command that runs the tests.

Week 2. Pick a small accepted job and ask first#

Do:

1. Find an issue with a newcomer-friendly label (such as good first issue) that nobody has claimed.
2. Read the issue and its comments carefully. An issue confirmed by a maintainer is worth doing.
3. Comment to ask to take it, describe your planned approach in two or three sentences, and wait for an answer before writing code.
4. If nobody answers for several days, do not push ahead with a large change. Ask again or pick another job.

Take away: one short, polite, clear comment that a maintainer has answered.

Week 3. Make a small, tested change you understand#

Do:

1. Create your own branch. Write a failing test that reproduces the problem, then fix it until the test passes.
2. Keep one single purpose. Do not reformat files or rename things in bulk in the same PR.
3. Run the project's whole test suite and note how many tests ran.
4. Use AI if the project allows it, but take this test: switch the AI off and explain every line you changed out loud, to someone else or to yourself. Where you cannot explain, you do not understand yet, and you are not ready to submit.

Take away: one branch with one clean commit and a test that runs.

Week 4. Open a clear PR, disclose AI and take feedback calmly#

Do:

1. Write the PR description with the template in section 5: problem, fix, how to check, and the AI disclosure line the project asks for.
2. Review your own diff before sending (see Reviewing AI-written code).
3. When feedback arrives, reply briefly, change exactly what was asked, and rebase if the project has moved on.
4. If it is rejected, say thanks, ask if it is unclear, and do not argue.

Take away: a PR whose purpose and checking method the maintainer sees at a glance.

---

4. A real walkthrough: the git flow of one small contribution (skip it if you do not use git yet)#

Picture practising in a mock workshop before entering a real one. I built a "mock workshop" on my machine: a bare repository as the project's "original", and a clone as "your fork". I really ran every command below with Git 2.56.0 and Python 3.14.8. Commit hashes will differ on your machine.

Note: this is not GitHub. On GitHub you press Fork on the web, push a branch to your fork and open a pull request on the web. What they share are the git commands: branch, commit, rebase, amend. In the example the "project" is a small library called textkit with a slugify function that turns a title into a short piece of a web address. The "problem" is that slugify("Hello World!") returns hello-world- with a stray dash at the end.

4.1 Before fixing: run the tests, create a branch#

$ python3 -m unittest -q
Ran 1 test in 0.000s

OK

$ git switch -c fix-slug-trailing-dash

My first run failed silently. It printed "Ran 0 tests" and "NO TESTS RAN", because the tests folder lacked an __init__.py file so the test runner found nothing. No line was red, no test ran. That is exactly why Make AI Output Prove Itself tells you to always note how many tests ran: "no errors" does not mean "checked".

4.2 Write the failing test first#

I added a test for a case with an exclamation mark and spaces at both ends, then ran it before fixing:

$ python3 -m unittest -q
FAIL: test_no_trailing_dash (tests.test_slug.SlugTests.test_no_trailing_dash)
Traceback (most recent call last):
  File "tests/test_slug.py", line 10, in test_no_trailing_dash
    self.assertEqual(slugify("Hello World!"), "hello-world")
AssertionError: 'hello-world-' != 'hello-world'

Ran 2 tests in 0.000s

FAILED (failures=1)

The test fails for exactly the expected reason. If a test passes straight away before the fix, or fails for another reason, it is checking something other than your problem.

4.3 Fix and rerun#

$ python3 -m unittest -q
Ran 2 tests in 0.000s

OK

$ git diff --stat
 tests/test_slug.py | 4 ++++
 textkit/slug.py    | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

Two files, five lines added and one changed: small enough for a maintainer to look at in a few minutes.

4.4 A commit with a clear message and a disclosure line#

fix(slug): strip leading and trailing dashes

slugify("Hello World!") returned "hello-world-". Strip dashes at both
ends and add a test for punctuation and surrounding spaces.

AI assistance: used an AI tool to draft the test; I read and ran it.

The last line is one way a project may ask for disclosure. Use the way of the project you contribute to, not this template.

4.5 The project moved on: fetch and rebase#

While you worked, the maintainer pushed one more commit to the main branch. You fetch it and move your change on top of the latest version:

$ git fetch origin
$ git log --oneline --graph --all
* 4cbdd85 docs: add a line on review etiquette
| * 0606d8e fix(slug): strip leading and trailing dashes
|/
* 7835b68 chore: initial textkit

$ git rebase origin/main
Successfully rebased and updated refs/heads/fix-slug-trailing-dash.

$ git log --oneline --graph --all
* ea41359 fix(slug): strip leading and trailing dashes
* 4cbdd85 docs: add a line on review etiquette
| * 0606d8e fix(slug): strip leading and trailing dashes
|/
* 7835b68 chore: initial textkit

The same change got a new hash (from 0606d8e to ea41359) because it now sits on a new base. The old commit 0606d8e still sits on the branch pushed earlier.

4.6 Reviewer feedback: amend and push the new version#

Suppose the reviewer asks for one more test, for the empty string. I add the test, run it, then amend the old commit rather than adding a patch-up commit:

$ python3 -m unittest -q
Ran 3 tests in 0.000s

OK

$ git commit --amend --no-edit
$ git push --force-with-lease origin fix-slug-trailing-dash
 + 0606d8e (old), d109624 (new): branch fix-slug-trailing-dash (forced update)

$ git diff origin/main --stat
 tests/test_slug.py | 7 +++++++
 textkit/slug.py    | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

Real Git prints one line joining the old and new hashes with its own symbols; I rewrote it for readability, and the result is that hash 0606d8e was replaced by d109624 on the server. --force-with-lease only overwrites when the branch on the server is what you expect. Use it only on your own branch (the PR branch), never on the project's main branch. Some projects want you to add new commits instead of amending, so check the project's guide.

4.7 Another way: make a patch file#

Some communities accept changes as patch files sent by email:

$ git format-patch -1 -o ../patches
../patches/0001-fix-slug-strip-leading-and-trailing-dashes.patch

This is rarer on GitHub but still used by many large projects. Each project's CONTRIBUTING says which way it uses.

A note on the example: it is a one-person practice repository, with no real reviewer and no web interface. It shows the commands run and give the output pasted here, not how a real conversation goes.

---

5. A PR description template and a self-check list#

5.1 Pull request description template#

## Problem
One or two sentences: what is wrong, when you hit it. Link the issue (Closes #123).

## Fix
One or two sentences: what you changed and why this way.

## How to check
- Test command: python3 -m unittest
- Tests run: 3, all pass
- New test failed before the fix: yes

## AI disclosure
As the project requires: whether AI was used, which tool, for which part.
I have read, run and understood the whole change.

5.2 Six-question self-check before you press send#

1. Can I explain every line of the change without AI?
2. Did I run the project's whole test suite, and do I know how many tests ran?
3. Does this PR have one purpose only?
4. Have I read the project's CONTRIBUTING and AI policy, and followed them?
5. Has a maintainer accepted this job in the issue?
6. Does the description say how to check, so the reviewer can follow along?

If any answer is "no", stop and finish that first.

---

6. Common mistakes#

Picture the visitor in the workshop: some things visitors do make the owner sigh.

---

7. Illustration: two mornings with the same issue#

This is an illustration that names no real person or project. Two contributors see the same small issue.

The first does not read the rules:

• 09:00. Opens the issue, sees an "easy job", asks AI to generate code.
• 09:40. The AI produces a 600-line change that includes reformatting three files and an extra optimisation. The contributor has not read it all, opens a PR with no AI disclosure.
• 14:00. The maintainer closes the PR with a reminder to read CONTRIBUTING: the work was not accepted and is too large. The contributor lost a morning and does not know what went wrong.

The second follows the four-week plan:

• 09:00. Reads CONTRIBUTING and sees the project requires AI disclosure and asking first.
• 09:20. Comments to ask to take the job, describing the fix in two sentences.
• Next day, 10:00. The maintainer replies "Fine, go ahead".
• Next day, 15:00. Writes the failing test first, fixes, runs the whole suite, rereads every line without AI, then opens a PR that adds only about 8 lines, with the disclosure line.
• Day three, 09:00. The reviewer asks for one more test and the contributor amends in 15 minutes.

What to do: stop yourself at the ask-first step and the explain-yourself step. These two steps cost about half an hour, but often save both sides a whole morning.

This illustration is not evidence. The evidence is the Linux Foundation survey and the curl case in section 2: real maintainers are under heavy load and closing doors, so a contribution that is easy to review is a real gift. Those two sources are estimates and an insider's account, not controlled experiments.

---

8. Exercises with answers#

Exercise A. Find the flaws in a PR description#

A PR description reads: "Fix stuff. Fixed the bug, used AI to be quick. Also reformatted the whole folder. Tested."

Find at least five weaknesses.

Answer: (1) it names no concrete problem and links no issue; (2) "used AI to be quick" names no tool, no part, and does not say you read and understood it; (3) reformatting the whole folder is a second purpose and belongs in a separate PR; (4) "Tested" gives no command, no test count, and does not say whether the new test failed before the fix; (5) there is no way for the reviewer to check it themselves; (6) the title "Fix stuff" says nothing.

Exercise B. Ask first or do it now?#

In the practice repository, slugify("Xin chào") returns xin-ch-o (I really ran this). You see accented letters disappear. Should you open a fixing PR straight away or comment first?

Answer: comment first. How to treat accented letters is a design decision: strip the accents (xin-chao), keep them, or transliterate. The maintainer may have a reason for the current behaviour or want a different approach. Opening a PR at once may get it closed even if your code works. A comment of two or three sentences describing what happens, a few options, and asking which direction they want is enough.

Exercise C. A test that passes before the fix#

You add a test slugify("Hello---World") == "hello-world". Running it passes at once with no change (I really ran this). What do you do?

Answer: this is not a bug. The function already collapses runs of dashes into one. A test that passes already may still be worth adding to protect existing behaviour, but it is not evidence that you fixed a bug, and it should not be packaged as a "fix". Go back and look at what the real problem is.

---

9. A balanced view: what is known, what is not#

Fairly solid: maintainers report growing contribution volume with a notable share of low quality; at least one large project (curl) closed a door for this reason; some projects (such as Ghostty) have clear AI policies.

Unclear or worth caution:

• The 25% and 31% figures are survey respondents' estimates, not a count. I have not read the full report.
• The curl case is one project, one insider, and the cash bounty may make it different from projects without one.
• Policies change fast. This post states only what I read at the time of reading.
• I have not seen research measuring directly whether following the four-week plan raises the rate of being merged. The plan is a synthesis of practice, not an experimental result.

Do not overstate. Nothing guarantees your PR will be accepted. A project may refuse for reasons unrelated to you: a release freeze, a change of direction, or simply running out of energy.

Do not downplay. Some projects ban AI-generated contributions outright. When you meet one, comply and do not try to get around it.

---

10. Conclusion#

Contributing to open source in the AI era is an act of respect: read the rules first, ask first, send little and send it easy to review, and understand what you send. AI helps you write faster, but it also helps you send things you do not understand faster. The four weeks above put the stopping points in the right places.

If you want to practise this git flow, do it in a practice repository first. See also Git for People Who Use Agents for rescue commands, Debugging Like a Detective for reproducing a bug before fixing it, and Learning an Unfamiliar Library with AI Without Losing the Skill for learning a new project while keeping your craft.

---

References#

Figures come from public sources as of October 2026. Individual projects' policies may have changed, so open the sources to check before you act.

• Linux Foundation, press release on the survey "Navigating Open Source Software Development in the Generative AI Era" (20 October 2026) and a news summary
• Daniel Stenberg, The end of the curl bug-bounty (26 January 2026)
• GitHub Changelog, New repository settings for configuring pull request access (13 February 2026)
• Ghostty, CONTRIBUTING.md and AI_POLICY.md (read in October 2026, the policy may have changed)
• Git, the git-rebase, git-push (--force-with-lease) and git-format-patch documentation