[Dev] Community goals for Chandler 0.7: QA

[Mike Taylor]

IMO if you are not going to record some way of communicating back to  
the user that the bug has been fixed/worked on/whatever then you may as  
well just toss it  into the bit bucket.

If you have no-brainer bug data entry then we will need someone to walk  
thru them and weed out all of the chaff.

On Jan 12, 2006, at 6:04 PM, Philippe Bossut wrote:

> +1 on Alec's proposal. We should log a Bugzilla record and put that on  
> the schedule somewhere.
> Cheers,
> - Philippe
>
> Alec Flett wrote:
>
>> Heikki Toivonen wrote:
>>
>>> Is this too hard?
>>> https://bugzilla.osafoundation.org/enter_bug.cgi? 
>>> product=Chandler&format=guided
>>>
>>>
>> Yes.
>>
>> This is what I think we need: A web form with no more than 5 fields  
>> and a submit button. That's it. No multi-part account-creation and  
>> searching for previous bugs. 5 fields seems like a good maximum, I'd  
>> say even fewer is better. One of those fields should be an optional  
>> e-mail address, and one of those fields needs to be a free form  
>> comment area.
>>
>> The only other things that I think we'd want to collect are:
>> 1) platform - mac/win/linux - that's it, nothing else
>> 2) type of feedback - bug, suggestion, complaint, etc
>> 3) short description for our own records so we could view them in a  
>> table UI...
>>
>> There must be some open-source CGIs for doing just this somewhere...
>>
>> Alec
>>
>>> We need almost all of the info, but there of course are different  
>>> ways
>>> to ask for it, and gather some of it automatically. The less  
>>> information
>>> there is in the bug report, the more work it is for us to try and  
>>> figure
>>> out what to do with it.
>>>
>>> I really do think an email address should be required. When you take  
>>> a
>>> random person reporting a bug (possibly the first time in their  
>>> life),
>>> they are just not going to be filing a usable report. There needs to  
>>> be
>>> some back and forth between the reporter and us to figure out what  
>>> the
>>> issue is exactly and how to reproduce it. Without the email, I fear  
>>> we
>>> would just be wasting time with unintelligent reports that we  
>>> eventually
>>> need to close as INVALID.
>>>
>>> Now the "talkback" tool that I will be working on for 0.7 is  
>>> something
>>> that could be anonymous (although email address can be provided) -
>>> basically a crash report or similar tool for Chandler. The idea with
>>> this tool is that it automatically gathers much of the data needed to
>>> fix a bug, so bad user comments don't matter so much. Also, the idea
>>> with this thing is that lots of reports will be aggregated and we  
>>> would
>>> be working on the most frequently reported issues and ignoring
>>> everything else.
>>>
>>> But its just not good to ignore regular bug reports.
>>>
>>>
>>> --------------------------------------------------------------------- 
>>> ---
>>>
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>
>>> Open Source Applications Foundation "Dev" mailing list
>>> http://lists.osafoundation.org/mailman/listinfo/dev
>>>
>>
>> ---------------------------------------------------------------------- 
>> --
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/dev
>>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev
>
>
---
Bear

Build and Release Engineer
Open Source Applications Foundation (OSAF)
bear at osafoundation.org
http://www.osafoundation.org

bear at code-bear.com
http://code-bear.com

PGP Fingerprint = 9996 719F 973D B11B E111  D770 9331 E822 40B3 CD29


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.osafoundation.org/pipermail/dev/attachments/20060112/75689d8d/PGP.pgp