You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Rob Weir <ro...@apache.org> on 2013/01/18 20:22:47 UTC
What to do with confirmed bugs?
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.
So how do we want confirmed bugs to get assigned to developers? 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?
Also, are we still using/looking at votes on bugs? Was that an
effective way of prioritizing?
-Rob
Re: What to do with confirmed bugs?
Posted by Albino Biasutti Neto <bi...@apache.org>.
Hi
2013/1/18 Rob Weir <ro...@apache.org>:
> 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!
So good ! :-)
Albino
www.techbino.net
Re: What to do with confirmed bugs?
Posted by Andrea Pescetti <pe...@apache.org>.
Rob Weir wrote:
> We have 50 new QA volunteers, in just the first two week of January!
Really impressive!
> Also, are we still using/looking at votes on bugs? Was that an
> effective way of prioritizing?
Votes should still be used to prioritize, especially for external
entities, like new developers, as Regina suggested, or
companies/institutions who want to sponsor someone to fix a highly voted
issue (and then of course contribute the work to Apache OpenOffice).
Regards,
Andrea.
Re: What to do with confirmed bugs?
Posted by Rob Weir <ro...@apache.org>.
On Sun, Jan 20, 2013 at 3:54 PM, Kay Schenk <ka...@gmail.com> wrote:
> On Fri, Jan 18, 2013 at 2:04 PM, Rob Weir <ro...@apache.org> wrote:
>
>> On Fri, Jan 18, 2013 at 4:47 PM, Regina Henschel
>> <rb...@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
Re: What to do with confirmed bugs?
Posted by Kay Schenk <ka...@gmail.com>.
On Fri, Jan 18, 2013 at 2:04 PM, Rob Weir <ro...@apache.org> wrote:
> On Fri, Jan 18, 2013 at 4:47 PM, Regina Henschel
> <rb...@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
Re: What to do with confirmed bugs?
Posted by Rob Weir <ro...@apache.org>.
On Fri, Jan 18, 2013 at 4:47 PM, Regina Henschel
<rb...@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!
>>
>> 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
Re: What to do with confirmed bugs?
Posted by Herbert Duerr <hd...@apache.org>.
On 18.01.2013 22:47, Regina Henschel wrote:
> Rob Weir schrieb:
> [...]
>> 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?
AFAIK that is not longer possible in Bugzilla 4. There the voting
feature has been demoted to an extension [1] and things like searching
by vote have been removed completely [2] and the vote count is no longer
exported via its XML or JSON webservices.
[1] http://www.bugzilla.org/releases/4.0/release-notes.html#v40_feat_vot_ext
[2]
http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService/Bug.html#search
I hope that Bugzilla gets its full voting system features back as I
liked it and always consider the vote count when prioritizing issues.
Herbert
Re: What to do with confirmed bugs?
Posted by Regina Henschel <rb...@t-online.de>.
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.
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.
>
> 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?
Kind regards
Regina