On bug and bug reporting

A quite well established mindset with Open Source projects is that as much users a code base has, as much it will be tested and, therefore, will produce a continuosly growing quality product.

And it is true, indeed!

But what does it mean to test an Open Source project? Disregarding the low level testing with test suites, it means that true users will install, run and report back application misbehaviors, crashes, problems, and so on. And this is the point of this post: reporting back information to developers so that they could do their work and improve the software. I'm not focusing on how to write a good bug report, you can find a lot of information about in the net and in the project documentation itself. But have you ever thought about the importance to report as less information as possible to allow a developer to do her job? I mean: what do you think a developer will feel like opening the bug tracking system on the Monday morning and finding out tons of bug reports? Therefore, before posting a bug report, please ensure that none before you has openend the same report, and in case append to such report. You will achieve the goal of making the developer feel better and, most notably, to avoid wasting her time in reading just another report that reports the already known problem.

And if you have time, please provide a clear and short way to reproduce the bug, even if you are not the first reporter. Even better, write an automated test for the bug you are interested in: you will grant the developer some extra time to concentrate on the real bug instead of the aside artifacts.

And about testing allow me to spend some extra words: while it is very important to test the produced code, please consider that techniques such as Test Driven Development TDD not only promote the creation of tests ahead the code that implements a feature, but also that a feature should be requested due to a failed test.

In other word, if you want to add feature X to the project Y provide a short and clear test along with the feature request.

Why?

Because again, you are going to give the developer(s) some extra time and will help her better understanding what is your will. And most notably, while writing the test you will become a concrete part of the development and will better think about what you are asking (and why you are needing it). In other words: you will only ask something you can clearly explain and with as less as possible misunderstandings, while the developer(s) will have a concrete case to start developing on.

Fianlly, again on testing, please spend some time reviewing and providing new test cases for existing code, even if you don't have a feature request or a bug to work on.

Why?

Because Open Source developers often, or better almost always, do the hard work on their spare time, and will regret to implement some new code until they do not risk public embarassment. Therefore, if the code base has a strong and reliable test case, developers will be more likely to implement more code without having to worry about awkaward bugs.