On Sun, Jan 20, 2013 at 3:54 PM, Kay Schenk <kay.sch...@gmail.com> wrote: > On Fri, Jan 18, 2013 at 2:04 PM, Rob Weir <robw...@apache.org> wrote: > >> On Fri, Jan 18, 2013 at 4:47 PM, Regina Henschel >> <rb.hensc...@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
