openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: What to do with confirmed bugs?
Date Sun, 20 Jan 2013 22:03:27 GMT
On Sun, Jan 20, 2013 at 3:54 PM, Kay Schenk <kay.schenk@gmail.com> wrote:
> 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.
>

Right.  And end users often don't set version information accurately.

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

Right now I think we're limited to 5 votes per "product".  I think
that can be raised, but not sure if it can be raised for only QA.

A related approach might be to encourage end-users vote, remind our
users that this capability exists and is a form of feedback that this
project feels is valuable.  Maybe a blog post?

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

Process becomes easier once we clear out the backlog.  But maybe we
can do that faster with some sort of cut-off date.  Like all bugs
reported/not fixed since 2010-01-01 get "archived" or something, and
we concentrate on "current" bugs only.

-Rob

>
>> 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
View raw message