openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <kay.sch...@gmail.com>
Subject Re: What to do with confirmed bugs?
Date Sun, 20 Jan 2013 20:54:24 GMT
On Fri, Jan 18, 2013 at 2:04 PM, Rob Weir <robweir@apache.org> wrote:

> On Fri, Jan 18, 2013 at 4:47 PM, Regina Henschel
> <rb.henschel@t-online.de> wrote:
> > Hi Rob,
> >
> > Rob Weir schrieb:
> >
> >> I just did a tally of new volunteers who introduced themselves onto
> >> the QA mailing list since January 1st.  It came to a nice round
> >> number.   We have 50 new QA volunteers, in just the first two week of
> >> January!
>

SUPER!


> >>
> >> A good number have made it through the orientation modules, have a
> >> Bugzilla account and are starting to review bug reports.  We're hoping
> >> to clear out the backlog of unconfirmed bugs.  We've cleared out
> >> around 100 of them in the last week.
> >
> >
> > I have noticed your guidance for the new QA volunteers. A great and
> > important work!
> >
> >
> >>
> >> So how do we want confirmed bugs to get assigned to developers?
> >
> >
> > Not at all. There is the "take" link. If a developer is really working on
> > it, he assigns the bug to himself. Otherwise a volunteer does not know,
> > whether he can take a bug and try to solve it. Besides the cases, when
> > someone is told from his employer to do something, we are all volunteers
> and
> > nobody can "assign" work to someone else.
> >
> > In old days bugs were assigned to workers of Sun, if the bug belongs to
> > their area of work, later to a default, collecting address of that area
> of
> > work. Both do not work. There are now thousands of bugs, which are
> assigned
> > to persons, who are no longer working on OpenOffice at all.
> >
>
> I don't mean "assign" in that sense.  I mean more like, how do
> developers become aware of which bugs to self-assign?   We have
> something like 10000 confirmed defect reports.  This is not a small
> project where every developer can be expected to be aware of every
> report, and decide if they want to work on it.  We need to assume that
> the vast majority of bugs are unknown to most developers.
>

Oh boy! The thought of dealing with 10,000 confirmed bugs is truly
overwhelming.

Just a moment ago, I  took a look at confirmed bugs for the following
"target milestones":   AOO 3.4.0, AOO 3.4.1, AOO 3.5.0, AOO 3.x, AOO 4.0,
AOO 4.0.0, OOo 3.3, OOo 3.4, OOo 3.5, OOo 3.x

The number of bugs using this criteria amounted to 129. (I'm guessing these
were perhaps mostly developer entries.)

Another one I did using "versions" of: AOO 3.4.0, AOO 3.4.1, OOo 3.0, OOo
3.0.1, OOo 3.1, OOo 3.1.1, OOo 3.2, OOo 3.2.1, OOo 3.3

yielded 1234 bugs.

Probably more end-user entries on this one.

However, I don't doubt that there are MANY outstanding "old" bugs from
previous versions that might still be outstanding.

Would it be possible for the QA volunteers to maybe start with a query like
this and let them vote on what they consider most important for a week or
so?  This will not help with assignments, the initial concern, but maybe
after this we could take another look and make a better determination on
who should deal with what.

I don't have any better suggestions regarding "process" at the moment.


> I suppose someone could decide, "I am interested in looking at
> spreadsheet formulas today" and search specifically for those.
>
> Hmmm... How about a Bayesian classifier that looks at metadata for
> bugs you've fixed in the best and recommends which ones you might be
> interested in....
>
> >
> >   In
> >>
> >> the old days, I think we had default assignments for different
> >> components.  Does that make sense here?  Or do we want to use a view
> >> or report of confirmed defects, ordered by severity?
> >
> >
> > The "release stopper" bugs had work quite well. QA people or committer
> > nominate a bug by making a dependence there. If there are objections, it
> can
> > be discussed on mailing list and the dependence can be removed if
> required.
> > Every developer can track this issue and take a nominated bug. Whether
> such
> > bug is empty or not, can influence the decision, to nominate a build for
> > release to the Apache board.
> >
>
> Yes, that can work up to a certain scale.  But doing mailing list
> discussions of individual showstopper bugs implies that
> non-showstoppers bugs are handled some other way.
>
> 10000 confirmed bugs.  And another 3000 unconfirmed.  What to do?
>
> >
> >>
> >> Also, are we still using/looking at votes on bugs?  Was that an
> >> effective way of prioritizing?
> >
> >
> > It was the only way for users to get a little bit influence on the
> decision,
> > which feature will be implemented and what changes will be made. Now it
> > might help those, who come and say "I want to help in development, but do
> > not know in which area to work." Unfortunately it is no longer possible
> to
> > select "vote" as column and sort on it. Can you enable that?
> >
>
> I did look for that in the admin settings, but could not find it.
> Searched online and it suggested it was a non-default column but you
> could get to it by customizing columns at the bottom of search
> results.  But that column is not listed.
>
> > Kind regards
> > Regina
>



-- 
----------------------------------------------------------------------------------------
MzK

"No act of kindness, no matter how small, is ever wasted."
                                                                         --
Aesop

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message