I found this online article useful:
http://stormyscorner.com/2012/02/its-scary-to-join-an-open-source-project.ht...
I found Boudewijn Rempt's (lead maintainer of krita) comments insightful:
http://stormyscorner.com/2012/02/its-scary-to-join-an-open-source-project.ht...
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
On 02/28/2012 07:46 PM, Darrell Anderson wrote: <snip>
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
All of the ideas are excellent. Concerning the bugs specifically, is there a way the current bugzilla could sort or categorize bugs so that they are loosely grouped by the discipline needed to fix them? For those that don't require an in-depth level of c++ knowledge, etc., it may help those willing to help wade through and find something they could handle.
The submit patch, then review/approve is a great safeguard, but the review/approve still puts a significant demand on the reviewer/approver :)
It would even be a help if those who know/review the current active bugs could dump a list of "need help with this" to help prioritize which should be attacked first.
Just my "Comments? Ideas?"
All of the ideas are excellent. Concerning the bugs specifically, is there a way the current bugzilla could sort or categorize bugs so that they are loosely grouped by the discipline needed to fix them? For those that don't require an in-depth level of c++ knowledge, etc., it may help those willing to help wade through and find something they could handle.
Users can use the category header links to sort a list. There also is the advanced search.
Users can create and save various types of queries. I created one long ago but haven't spent much time exploring how to create killer queries. We probably could create some extensive queries and then provide links in the bugzilla header. Those new queries likely would provide what you ask.
Perhaps we all could take a look at creating various queries and then posting them to share.
The submit patch, then review/approve is a great safeguard, but the review/approve still puts a significant demand on the reviewer/approver :)
Possibly, but right now there is no feedback whatsoever, which is my primary goal. As a somebody who has posted many bug reports and enhancement requests, if I were not on the team helping I'd be left wondering whether there is any action in Trinity development. Not good public relations or image. Tim is only one person and can't do everything. If users expect that he can or will then this project won't last. :(
It would even be a help if those who know/review the current active bugs could dump a list of "need help with this" to help prioritize which should be attacked first.
I could select a dozen or two reports that people other than Tim likely could help resolve.
Many of the bug reports do not require years of C++ and Qt experience. I accept that everybody has busy lives, but a quiet commitment of helping with one or two bugs per week probably is not asking much.
I want Trinity to continue and succeed. Improving the feedback mechanism improves our image. I wonder how users feel about reports they filed long ago and have yet to receive a response? How do non team members know anything is happening or why their reports receive no attention?
Darrell
-
Darrell Anderson -
David C. Rankin