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