I found this online article useful:
http://stormyscorner.com/2012/02/its-scary-to-join-an-open-source-project.h…
I found Boudewijn Rempt's (lead maintainer of krita) comments insightful:
http://stormyscorner.com/2012/02/its-scary-to-join-an-open-source-project.h…
1. Can we modify our bugzilla to send an immediate reply to the filer:
"Hi XXX [this information is available when the user creates an account], thank you
for your bug report/enhancement request. Our general policy is to review and comment
within one to two weeks on all reports submitted."
2. We have discussed review boards. First, we need two or three people beyond Tim who is
willing to review new reports. (Yes, I volunteer. :) ) Thereafter, can we start a policy
as Boudewijn suggested that within a week or two somebody on the Trinity teams responds
with a comment? For example:
"Thanks XXX for helping! This is a build/compile issue. I elevated the bug report to
Blocker status."
"Thanks XXX for helping! I have confirmed this bug. This is a serious usability
issue. I elevated the bug report to Major status."
"Thanks XXX for helping! Although irritating, this is a seldom used feature. We
appreciate the frustration but we can get to this bug only after resolving those with a
higher status."
"Thanks XXX for helping! This sounds like a legitimate issue but manpower limits our
ability to dig deeper at this time. If you don't hear anything further in two months
please provide a comment."
Perhaps at the end of each initial response for reports marked Blocker, Critical, and
Major, we add the following statement:
"Please know that except under unusual circumstances, bug reports marked Blocker,
Critical, and Major will be resolved before the next official release."
Seems another good policy is providing a decent explanation any time a bug report is
resolved as WONTFIX. In that comment should be a statement that if anybody disagrees to
post comments why they disagree.
Lastly, we need people who have some skills to start helping with bugs. Many bugs do not
require C++ skills but require makefile, cmake, automake skills, etc. Other bugs require
little more than knowing how to use grep and sed once the solution is realized. People
don't need commit access, just get the patches submitted. Somebody who is qualified
will review the patch.
Comments? Ideas?
Darrell