bugs audit volunteers required

[James McKenzie]

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 at 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