[Libreoffice-qa] How to change QA processes: was: What should we do with bugs filed against Extensions/Templates?

[Petr Mladek]

Hi,

I will comment only pieces where I could add something new. I agree with
the rest :-)

On Mon, 2013-04-08 at 14:38 -0400, Robinson Tryon wrote:

> On Sun, Apr 7, 2013 at 4:22 AM, Rainer Bielefeld
> <LibreOffice at bielefeldundbuss.de> wrote:
> > a) We have a report without info concerning Version and OS, and a
> > confirmation for 1 Linux distribution. So current knowledge (for the moment)
> > seems to indicate a LINUX problem? Should the report leave QA process
> > ("NEW") without having this corrected or at least mentioned?
> 
> Based on my experience with the Ask site, it can sometimes be tough to
> ask the Reporter for additional information and get a useful answer
> (or any answer at all). Being able to reproduce a bug on more than one
> platform is nice, but if we don't have a very large QA team right now,
> and if some people don't have multiple OSes on which to test bugs, I
> can imagine that narrowing-down the affected Platforms might be
> something we consider lower priority than just getting a first-round
> confirmation on our outstanding set of UNCONFIRMED bugs.

I agree that it is low priority. The information is useful if it is
platform specific and it might need an expert on the given platform. 
On the other hand, I think that most of the bugs are not platform
specific. Developers always could ask for more info if they are not able
to reproduce.

> Proposal: Is it possible for us to do some of the additional triage
> work in subsequent "passes" over the bugs? What I mean is, if we work
> quickly to triage and repro a bunch of unconfirmed bugs, is there a
> good way that we can later query for bugs that, say, need to be tested
> on Windows to determine if they're platform-specific or
> cross-platform?
> 
> Such a system might help us to keep up with the rapid onslaught of new
> bugs while giving us the opportunity to go back and improve older bug
> reports as time allows...

I would personally leave this for developers. They could always ask for
more info and push it back to triage if needed. Anything else might be
to complicated.


> > i) May be I even would have tested whether the bug persists with new User
> > Profile? But I doubt that it's related and so I think I would have written
> > "I doubt that it's profile related"
> 
> I'm still a bit confused as to the nuances of the User Profile[1].
> It's great that we know that resetting it sometimes fixes weird bugs,
> but our approach to this problem seems kind of like voodoo at times.
> If we are concerned about the data in the profile being corrupted into
> an unexpected state, why don't we come up with a plan to verify the
> integrity of the profile? Given the number of times that I've seen a
> suggestion to reset the User Profile on the Ask site, it sounds like
> we could avoid a large number of bug reports though such an
> enhancement.

I think that it more about corner cases and broken functionality than
about corrupted data. For example, new version might stop working with
some crazy setting or crazy extensions.

In each case, the current approach is to ask user SAVE the old
configuration and attach it to the bug if the fresh configuration helps.
This allows use to find the root of the problem and fix it. For example,
Stephan Bergmann has improved a lot extensions hadnling, so new version
is able to survive more problems with crazy extensions.


> > k) And after having added all this information I would think about adding
> > András to CC. I agree with "minor" rating and we should not bother
> > developers with too many odds and ends, but on the other hand a known bug
> > can be integrated into the work flow for a fix some later.
> 
> Right. I wouldn't have known to cc: András in this situation... so
> that's an important piece of institutional knowledge.

You might find the list of experts at 
https://wiki.documentfoundation.org/FindTheExpert


Thanks for positive and constructive approach.

Best Regards,
Petr