I appreciate all form of contribution, but for some contributors a greater sense of awareness about how OSS works would go a long way. The more you leave undone in a pull request or the more you leave unanswered in a bug report, the more “work in progress” your contribution adds to a project.
So for example, say you report a bug, but you only explain it with a sentence or two of english -- no stack trace, no minimal example reproducing the problem, and no tests. At that point, there’s nothing I can do except ask you to provide more information to help me investigate further, unless your problem is very obvious the moment I look at it.
Once we at least have the means to reproduce a bug, we need to make sure it’s isolated and not coming from some lower level problem. That means writing further sets of examples, and poking around in the source until we’re fairly sure where the bug is coming from.
Once that source of the problem has been identified, we need to work on a fix, but we need to take care to make sure that our fix doesn’t introduce any unexpected behavior changes. In theory 100% code coverage would make this easier, but with reality being not so ideal, this too requires some knowledge of the way the software is used and meant to be used.
Once we sort all that out, we can add new tests or fix old ones to cover the regression, and this gives us a way to make sure that the bug has actually been fixed and will stay fixed. Of course, these tests need to be written at the right level, otherwise a future change may result in a similar bug recurring.
Once we’re fairly confident that there is adequate testing and that the fix works, we can turn our attention to the code quality of the fix, and consider its future maintenance costs, if any. We may also need to think about refactoring at this time if we found that the fix was hard to introduce without making the code messier or more brittle.
Finally, we may need to apply this change across multiple versions of our software. For example, Prawn’s master branch represents its next version, while its stable branch covers the current release line. We may need to rebase or squash to clean up history in the process of getting the fix merged, depending on how complicated it is.
Then we need to write up an entry in our release notes about the fix, and actually ship a new release. Hopefully nothing broke in the process of doing this, but if it did, we’ll need to start the process all over again.
In the case of a project like Prawn, there are dozens of open tickets at any given point in time, all in varying stages of quality and release readiness. So if you have one ticket open and it’s got three lines of text in it, and you expect a quick fix to happen (or even any fix at all), you’re going to have a bad time ;-)
Fortunately, many bugs really are shallow and so this process goes a lot faster than it sounds like it would. And for really important bugs, even if you don’t do the work yourself, someone else will come along and help move your issue along.
As long as you don’t have the expectation that your bug report or feature request will be acted on quickly, things pretty much work out ok.