Bad advices on contributing to open source projects.

[Roshanjossey]

There are people who wants to collaborate on open source projects and help others. There are also bad actors with ulterior motives, inexperience maintaining projects etc who end up giving some of the worst advices to people staring their open source journey. To identify if an advice is bad, think about it from maintainers' perspective. They have to spend time on reviewing your changes. if it doesn't improve the project, don't do it.

This discussion is to identify bad advices about open source contributions, discuss why they're bad and help more people to avoid them.

1. Improve Readme
   This is one I've observed to have done most damage.
   Some instances:
   - 2025 - https://socket.dev/blog/express-js-spam-prs-commoditization-of-open-source
   - 2020 - https://domenic.me/hacktoberfest/
   - 2020 - https://www.theregister.com/software/2020/10/01/open-source-devs-drown-in-digitaloceans-latest-tsunami-of-pull-request-spam-that-is-hacktoberfest/832083

   Even the pull requests we get here for changes in Readme are bad.
   If you're rephrasing a sentence or making small changes, don't do it.

2. Ask maintainers to assign an issue to you.
   I think this comes from a misconception that all open source projects works the same way. Read contribution guidelines of the project. If it suggests asking to be assigned, then do it. Unless don't. This is one of the biggest source of spam in issue threads

3. Add helpful comments in code
   These comments generally looks like this. They don't add any value. Just makes it worse

   // This is a class for a Car
       class Car {
       // constructor
       constructor() {
       // ...
     }
   }
   
   // increment the count
   count++;
   

4. Write small test cases for existing functionality
   These also tend to be trivial an end up not adding value

5. Refactor very small pieces of code without changing behaviour
   This is often maintainer time spent for no benefit

If you have come across some advices that you think is bad, comment down below

[abhyuday-fr]

This is such a great thread. I've definitely seen a lot of the ones you mentioned in the wild. A few other pieces of common "bad advice" come to mind that usually just end up creating massive headaches for maintainers:

1. "Just run a formatter over the whole repo." Beginners are sometimes told to run tools like clang-format or Prettier across the entire codebase to get an easy PR accepted. In reality, it totally wrecks git blame history, causes brutal merge conflicts for everyone else with open PRs, and is just a nightmare to review. If a project wants a global formatter, they'll set it up in their CI.

2. "If it doesn't build locally, change the config." Sometimes people are told that if a project fails to compile on their machine, they should submit a PR changing the Makefiles, CMake setup, or Dockerfile to fix it. Usually, it just means they missed a local dependency. Tweaking the core build pipeline to accommodate one specific local setup usually just breaks things for everyone else.

3. Random, unprompted micro-optimizations. I've seen advice telling people to hunt for standard loops and replace them with "faster" alternatives. Unless it's a known bottleneck backed up by actual profiling or flame graphs, submitting PRs to add complex bitwise hacks or weird memory management usually just makes the code way harder to maintain for zero actual benefit.

4. "DM the maintainer so your PR gets merged faster." I see this on social media a lot. Open source is mostly asynchronous volunteer work. Bypassing GitHub to ping a maintainer privately on Discord, Twitter, or email is intrusive and a pretty good way to annoy the exact person you want a review from.