openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: What to do with confirmed bugs?
Date Fri, 18 Jan 2013 22:04:40 GMT
On Fri, Jan 18, 2013 at 4:47 PM, Regina Henschel
<> 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!
>> 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.

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

View raw message