Open-source maintainers have always had too much to do. The new problem is volume that costs nothing to produce. A model can write a plausible issue, a plausible pull request, and a plausible comment in seconds. Reading each one, deciding whether it is real, and replying takes a person a great deal longer. The gap between writing and reviewing is where maintainers burn out.
I want to be specific about what that looks like, and then ask a question I think every contributor should answer for themselves: what are you doing here?
What the flood costs
A low-effort issue has a cost, even when it is closed quickly. Someone must read it, check whether it describes a real problem, reproduce it if it does, and reply. Multiply that by dozens a week, and the review queue grows faster than the team can clear it.
Pull requests are more expensive. A generated change may look tidy and still miss the point, touch files it should not, or fix a symptom while leaving the cause in place. The reviewer has to understand the change well enough to tell, which is the work the author skipped.
Comments and posts have the same shape. A reply that restates the question in polished sentences adds noise. A reply that says what was tried, what failed, and what the commenter now believes adds information.
What a human contribution looks like
For TDK CLI, the repository's own rules set the bar, and they are a good test for any contribution:
-
Sign off every commit. The Developer Certificate of Origin line is a statement that you have the right to submit the change. Adding it with
git commit -sis a small act of accountability, and the pull request check fails without it. - Keep one issue per pull request. A change that solves one thing is easy to review. A change that bundles several unrelated fixes is not.
-
Read
CONTRIBUTING.mdbefore you start. It explains the labels and the process, and a contributor who has read it asks better questions. -
Check lint by its exit code. Run the same command as CI and read the status. A pipe into
tailcan hide a failure, and a reviewer should not have to find it for you.
None of these is hard. Each one shows that the author has looked at the project before asking it for time.
What a good issue looks like
The most useful issue has five parts: what you ran, what you expected, what happened, the exact error or output, and the version you used. The Hacktoberfest issues in the repository are a good model. Many have a clear goal, the files involved, and a sentence on what done looks like.
If you cannot reproduce a problem, say so and say what you tried. That is still a contribution.
What I am asking
If you are a human, here is what I would like to know before you open the next issue or pull request:
- Did you run the thing yourself?
- Did you read the file you are changing?
- Can you explain the change without reading the summary the tool gave you?
- Would you be willing to answer a review question about it next week?
If the answer to the last two is no, the change is not ready. Keep it in your branch until it is.
Use the tools, but own the result
AI tools are useful in open source. They can help you find the file, draft a test, or explain an error. Use them the way you would use a good search engine, and check every claim they make against the code and the docs. The person whose name is on the pull request is responsible for the change, whatever wrote the first draft.
Summary
The flood of generated content is not going to stop by itself. What a project can control is the bar for a contribution. Sign off your commits, keep changes small, read the rules, run the checks, and be able to explain what you changed. If you are a human, that is what this place is for.
