[Libreoffice-qa] Stagnant NEEDINFO bugs

Marc Paré marc at marcpare.com
Mon Jan 28 04:38:43 PST 2013


Le 2013-01-28 08:13, Petr Mladek a écrit :
> On Mon, 2013-01-28 at 10:05 +0100, Rainer Bielefeld wrote:
>> Petr Mladek schrieb:
>>> This will cause many mails only in the first round. It will be normal
>>> level of mails if we do this regularly.
>>
>>
>> Hi,
>>
>> That's an illusion, total number of mails will always be the the same.
>> Only the number of mails per cleanup will be smaller.
>
> IMHO, there is a difference when you get 100 mails now because we want
> to clean up the current "mess" or when you get 5 mails per week when we
> do this regularly.
>
>> BTW, I dislike the "noise" the discussed "3 strikes" solution will
>> cause. I'm thinking about a different solution:
>
> I am against 3 strike solution as well :-) My opinion is that it would
> cause to big traffic and do not help much. If people does not react for
> the first warning, there is only small chance that they would react on
> the second or third one.
>
>> Strike 1:
>> Query will find NEEDINFO bugs untouched for a long time and fulfilling
>> some additional "hopeless criteria".
>> Reporter's of these bugs will get polite mail with request to contribute
>> additional info that we will have to close the bug without additional
>> info. This mailing  only send mails to reporters, will not change any
>> info in the Bugs, so that data as "Days since last change" and similar
>> will be available for other queries. List of related bugs will be
>> published on QA list
>>
>> That's not a big technical challenge, I think I can create required
>> tools (what can be used fur further actions in future easily) within 1 hour.
>>
>> Strike 2 After 7 Days:
>> Query for all Bugs for what mails have been sent in Strike 1:
>> - Changed since mail (probably by reporter): QA will take care
>> - NOT changed: Mass close via Bugzilla with polite message
>>     "Sorry ..., but feel free to reopen if ..."
>>
>> What do think?
>
> I like this solution. It is polite and creates only one change in
> bugzilla.
>
>> BTW, I would not do that too often. Sometimes it's simply not easy for
>> reporter to contribute desired info, for example because bug is not
>> simple to reproduce. May be such bugs can be marked by entry of a QA
>> "Mentor" in QA contact or similar.
>
> I would do this regularly to keep bugzilla clean and avoid masschanges
> in hunderts of bugs. There are different reporters, so we will not touch
> the same reporter in each round. IMHO, the most important is to give
> user chance to answer before the first warning (30 days or so).
>
>
> Best Regards,
> Petr
>
>

Sure, then no problem with this, but, let's not forget that some of our 
users are reporting in EN and that this may not be their 1st language. 
If it needs more info, we should also try as well to look at it enough 
to try at first to fill in the blanks ourselves. The bug report may be 
critical enough to look at.

I would also be concerned that whoever is triaging may themselves have 
trouble understanding the report and just dismiss it as "needinfo" and 
then send it back to the user. Many users would then see it more as a 
sign of apathy on our part thinking "I submitted the bug and they are 
just not interested in fixing the problem I told them about ..."

Add to this that our users all have lives, jobs etc. and that the bug 
reporting takes time to submit on their part and that for most it is to 
help us with having LibreOffice work the right way. So, we should not 
send users messages in any way that may sound like their bug is useless; 
the message should be really appreciative of their time that they have 
given us in reporting the bug and that we would really like to fix it 
but it needs just a little more information for us to understand the 
problem. We need to keep them engaged in the bug reporting process.

Cheers,

Marc

-- 
Marc Paré
Marc at MarcPare.com
http://www.parEntreprise.com
parEntreprise.com Supports OpenDocument Formats (ODF)
parEntreprise.com Supports http://www.LibreOffice.org



More information about the Libreoffice-qa mailing list