I mostly write code for personal projects and had almost never contributed to an open-source project before. About seven months ago, I needed a CORS wrapper for an iOS Shortcut, so I found an outdated project that could be deployed with Cloudflare Workers. It had several issues, so I learned Cloudflare Workers, fixed those problems, added Cloudflare-specific functionality, and expanded the README with usage instructions. I also added a usage page to the project's small website.
The work mostly affected one JavaScript file and the README, but the resulting pull request had 22 commits and expanded the original JavaScript file from roughly 167 lines to more than 500. It also placed around 130 lines of HTML directly inside the JavaScript file, kept many nested functions in one export block, and included extensive comments. The pull request description began with "Many, many things have changed" and listed several fixes and features rather than presenting one focused goal.
The pull request received a few positive reactions, but other people called it "AI slop." Months later, the project owner closed it using that description without explaining what specifically needed to change. I did not use AI to write the code, but I can now see that the contribution may have been too broad, difficult to review, and inconsistent with the project's existing structure.
What should I have done differently? Should I have opened an issue or discussed the proposed changes before writing them? Would it have been better to make a fork instead? How should I divide a large set of changes into smaller pull requests, and what is the right amount of commenting and documentation?
5 Answers
There is also a social side to this. Open-source maintainers are not automatically asking for someone to redesign their project. Even if your changes work and solve a real problem for you, they may not fit the maintainer’s goals, preferred architecture, or willingness to support another deployment platform.
A good first contribution is deliberately small: a typo fix, a focused bug fix, a test, or a narrowly scoped documentation improvement. That lets you learn the project’s conventions and gives the maintainer a manageable way to build confidence in your work. If the owner does not respond or rejects the idea, your fork is still a perfectly valid place to maintain the broader version you wanted.
Do not let the “AI slop” label convince you that you should never show your code again. The owner may have been dismissive, but the technical feedback is actionable: reduce the scope, preserve the project’s structure, separate files when appropriate, and communicate before doing a large amount of work.
There is no universal line such as “over 50 changed lines is bad.” A 200-line bug fix can be easier to review than a 20-line patch that mixes unrelated behavior. The important questions are whether the change has one purpose, whether every line supports that purpose, whether it matches the existing project, and whether the maintainer actually wants it.
The commit history and pull request description also made the change harder to review. Twenty-two commits, including several small README edits, can make it difficult to follow the actual implementation. Work however you like locally, but before submitting, organize the history into a few meaningful commits or squash it if that is the project’s convention.
Lead with the problem and intended result, not a long inventory of everything you touched. A strong description might say: “Fix incorrect CORS handling for requests with a particular header, add tests, and update the documentation.” Then explain the approach, testing, compatibility concerns, and anything the maintainer should pay attention to. “Many things have changed” immediately signals that the reviewer may be facing a kitchen-sink patch.
The original file was small, but the contribution made it several times larger without introducing much separation. The HTML embedded in JavaScript is especially difficult to maintain, and putting everything inside one large exported function with nested helpers makes the structure harder to understand. Cloudflare examples often put everything in one file for demonstration purposes, but a real project should usually separate templates, handlers, and supporting logic when the code grows.
Also, a comment is useful when it explains why something unusual is necessary or documents an important constraint. Comments that merely narrate obvious code, explain temporary experiments, or defend questionable pieces tend to add noise. Before submitting, remove anything you already consider useless, refactor the inflated file, and make sure the code fits the project’s existing style.
The biggest problem is scope, not the number of comments. A pull request should usually have one clear purpose that can be explained in a sentence or two. This one bundled bug fixes, new features, Cloudflare-specific behavior, documentation, and a website change, so a maintainer would have to review a large amount of unfamiliar code without knowing which parts were actually wanted.
For future work, check whether an issue exists, or open one describing the problem and proposed solution. Wait to see whether the maintainer wants that work before investing in a large implementation. Then submit one focused change at a time. If several changes are genuinely needed, separate them into logical pull requests that can be reviewed or reverted independently. A large fork may be the better home when you are effectively creating a different version of the project.
That makes sense. I had assumed maintainers would simply request changes in the pull request, but I understand now that an unsolicited rewrite can create a lot of review work before they have even agreed with the direction.
So the issue was not literally that every function had a comment. It was that the comments, oversized diff, and awkward structure made the whole contribution look unpolished and difficult to trust.