If you want more pull requests, start by writing better issues.
From my own experience, on both sides, most people do not avoid contributing because they are lazy. They avoid it because the cost of entry is unclear. You do not know how much context you need or whether you will spend a weekend only to be told that is not what was meant. Clear issues remove that fear and shows respect for the contributor’s time.
The same applies to the codebase itself. If I can clone the repo, run it and understand the basic flow without reverse engineering everything, I am far more likely to help. Poor documentation does not just slow people down. It quietly filters contributors out.
Granularity matters too. Smaller, well scoped issues are simply less i...
If you want more pull requests, start by writing better issues.
From my own experience, on both sides, most people do not avoid contributing because they are lazy. They avoid it because the cost of entry is unclear. You do not know how much context you need or whether you will spend a weekend only to be told that is not what was meant. Clear issues remove that fear and shows respect for the contributor’s time.
The same applies to the codebase itself. If I can clone the repo, run it and understand the basic flow without reverse engineering everything, I am far more likely to help. Poor documentation does not just slow people down. It quietly filters contributors out.
Granularity matters too. Smaller, well scoped issues are simply less intimidating. That first small merge often turns into a second pull request, then a third. Large and fuzzy issues rarely get that first step.
None of this is meant to be flashy or inspirational. I just realized, that after I changed my maintainer habits a bit and followed these guidelines, way more new contributors entered the repo, which is a great feeling :)