Jan Zerebecki wrote:
On Mon, Dec 31, 2007 at 06:49:56PM -0600, Austin English wrote:
On Dec 31, 2007 6:42 PM, James McKenzie jjmckenzie51@sprintpcs.com wrote:
I agree. If you cannot find the application or a demo version to work with, how can you fix the bug. Logs and other helpers go a long way. Maybe an intro page as to what is needed and how to get it. This will become more and more critical as the project approaches 'release' status (1.0). Also, marking bugs as having insufficient information to fix advises the reporter that the project needs more information to help or troubleshoot.
Maybe add a resolution of NEEDMOREINFO?
We could add flags for "needs more information" and perhaps one for "reproducible bug report with enough initial information".
(A flag is something that can be requested to be set and can then be granted or denied by someone who was given the required rights.)
A resolution is much better. Using a flag of needsmoreinfo usually does not get answered.
Clicking on the "NEW BUG" link should take a person to a web page with reporting criteria. At this point, the reporter will read through a page of what should be done to report a bug. After clicking a 'I read and understand the reporting requirements', then the reporter will be able to submit a bug. After a few cycles of this, regular reporters will not be subject to this page and will be taken instead to the regular bug reporting page. For the occasional reporter, this is a good way to handle bug reports, IMHO.
Our bugzilla is in git, patches are welcome.
I think a small and easy explanation on the new-bug form, that refers one to a wiki page for the full guide is a good thing.
I like the recommendation that a page be read before submitting bugs. There are a growing number of duplicates (I'm responsible for at least one of them and I've been at the bug business for a long time) and incomplete reports points to the need for a readme type of page. The regulars should not be subject to reading the page (this could be a cookie function that just counts the number of bugs submitted and should be a very simple cookie as far as name and function.)
(I guess it's probably hard to filter bad bug reports automatically and even harder to not inconvenience our good bug reporters at the same time.)
+1 to this. Automatic filtering can lead to some necessary reports being skipped or deleted when additional, useful information will make them usable.
Thank you for taking time to read through my suggestions as well.
One last comment, the OpenOffice.org project (I think) stopped the ability for anyone without the canconfirm permission to reopen a bug. I might want to look at this in the future if time allows.
James