I agree with Jörg, I think the first step is to decide and assign Triage Owners to each component and not rely on one or a few developers to handle all of them. After defining the Triage owners, we should define time slots which will be dedicated to bug triaging. Maybe 1 hour per day, every day? Or once every 2 days? I recommend defining some strict slots, each based on the owner's availability, and follow them on a weekly basis, instead of trying to do it when there's some downtime, which it's mostly never. Cheers, On 2019-08-11 3:40 a.m., Jörg Knobloch wrote: > > Hi folks, > > the subject is a little long, so let me repeat it here: > > When is the Thunderbird project going to introduce timely and complete > bug triaging and assignment of triage owners who will actually also > look at the bugs in their component? > > This is an evergreen issue, and as far as I can see, bug triaging is > still left to chance and the initiative of volunteers ... and > Benjamin, who's been thrown in at the deep end. > > Our friends from Mozilla triage their bugs, put them into components, > assign priorities P1 to P3, and each component has a triage owner. > > Not so in our project: Looking at new bugs in Thunderbird and MailNews > Core in the last 300 days, https://mzl.la/2ZStSSP, I see 871 bugs, 174 > of which are in the untriaged component (20%), so chances are the no > one has looked at them. > > Emma took the time to explain all the things Mozilla do with their > bugs, and although they can't fix all bugs, they at least have a > system by which someone familiar with the component looks at them and > takes a decision. Emma also pointed out that looking at enhancement > requests is important for product planning. She offered her help with > auto-classifying bugs, etc., but all that help won't help us if we > don't finally take care of proper triaging. > > Let me repeat why proper triaging is necessary: > > 1. We need to detect regressions. > 2. We need to get a proper feel for buggy components to include > improvements in the product planning. > 3. We need to collect enhancements for product planning. > 4. We need to close duplicates. > 5. We need to weed out support requests. > 6. We need to get back to the reporters and give them some answer in > a semi-timely fashion. > 7. And we might even see some bugs that can be fixed more or less "on > the spot" without having to include them in the big planning scheme. > > So when will Thunderbird introduce something like Mozilla already has? > > Jörg. > > > _______________________________________________ > Maildev mailing list > Maildev@lists.thunderbird.net > http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net -- *Alessandro Castellani* Lead UX Architect Thunderbird

1. We need to detect regressions.
2. We need to get a proper feel for buggy components to include
improvements in the product planning.
3. We need to collect enhancements for product planning.
4. We need to close duplicates.
5. We need to weed out support requests.
6. We need to get back to the reporters and give them some answer in a
semi-timely fashion.
7. And we might even see some bugs that can be fixed more or less "on
the spot" without having to include them in the big planning scheme.

Thanks for your patience, I'm on PTO this week and next, but wanted to follow up when I saw this. Alessandro suggestion for the next step is the right one. My understanding from previous conversations on this was a resource constrain on triage owners and time might make it difficult for people to take on the role? You will also benefit from time boxing your decisions on triage, such as first looking at the last 3 months of bugs, then the previous 3 months out to a year or so. Triage owners on Firefox focus on the current release cycle and that's what we report out on. I'll be back in the office on the 26th and happy to talk more then. -- Emma (currently on BST in Dublin) On Tue, Aug 13, 2019 at 6:09 PM Alessandro Castellani < alessandro@thunderbird.net> wrote: > I agree with Jörg, > > I think the first step is to decide and assign Triage Owners to each > component and not rely on one or a few developers to handle all of them. > > After defining the Triage owners, we should define time slots which will > be dedicated to bug triaging. Maybe 1 hour per day, every day? Or once > every 2 days? > > I recommend defining some strict slots, each based on the owner's > availability, and follow them on a weekly basis, instead of trying to do it > when there's some downtime, which it's mostly never. > > Cheers, > On 2019-08-11 3:40 a.m., Jörg Knobloch wrote: > > Hi folks, > > the subject is a little long, so let me repeat it here: > > When is the Thunderbird project going to introduce timely and complete bug > triaging and assignment of triage owners who will actually also look at the > bugs in their component? > > This is an evergreen issue, and as far as I can see, bug triaging is still > left to chance and the initiative of volunteers ... and Benjamin, who's > been thrown in at the deep end. > > Our friends from Mozilla triage their bugs, put them into components, > assign priorities P1 to P3, and each component has a triage owner. > > Not so in our project: Looking at new bugs in Thunderbird and MailNews > Core in the last 300 days, https://mzl.la/2ZStSSP, I see 871 bugs, 174 of > which are in the untriaged component (20%), so chances are the no one has > looked at them. > > Emma took the time to explain all the things Mozilla do with their bugs, > and although they can't fix all bugs, they at least have a system by which > someone familiar with the component looks at them and takes a decision. > Emma also pointed out that looking at enhancement requests is important for > product planning. She offered her help with auto-classifying bugs, etc., > but all that help won't help us if we don't finally take care of proper > triaging. > > Let me repeat why proper triaging is necessary: > > 1. We need to detect regressions. > 2. We need to get a proper feel for buggy components to include > improvements in the product planning. > 3. We need to collect enhancements for product planning. > 4. We need to close duplicates. > 5. We need to weed out support requests. > 6. We need to get back to the reporters and give them some answer in a > semi-timely fashion. > 7. And we might even see some bugs that can be fixed more or less "on > the spot" without having to include them in the big planning scheme. > > So when will Thunderbird introduce something like Mozilla already has? > > Jörg. > > _______________________________________________ > Maildev mailing listMaildev@lists.thunderbird.nethttp://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net > > -- > *Alessandro Castellani* > Lead UX Architect > Thunderbird >

Before identifying who, should we not define for Thunderbird what a triage owner is and does? Maybe it's not the same as Firefox. Maybe not all owners need to be devs.   Surely doesn't all need to be staff - Thunderbird is, after all, still a community project. Perhaps also determine where we most need triagers, and allocate (to some degree) based on bug volume (more below) . Also, what is the overall expected outcome, i.e. how do we measure success - NN% triaged, to what status, within what # of days?   (We can probably estimate how many more person hours are required based on the many hours we collectively put in every day to triage just a percentage of bugs - I'd bet it's a pretty big number) More items below - not to be nit-picky, but mostly to add data On 8/13/2019 1:09 PM, Alessandro Castellani wrote: > > I agree with Jörg, > > I think the first step is to decide and assign Triage Owners to each > component > see above > and not rely on one or a few developers to handle all of them. > yes!  see below > After defining the Triage owners, we should define time slots which > will be dedicated to bug triaging. Maybe 1 hour per day, every day? Or > once every 2 days? > > I recommend defining some strict slots, each based on the owner's > availability, and follow them on a weekly basis, instead of trying to > do it when there's some downtime, which it's mostly never. > > Cheers, > > On 2019-08-11 3:40 a.m., Jörg Knobloch wrote: >> >> Hi folks, >> >> the subject is a little long, so let me repeat it here: >> >> When is the Thunderbird project going to introduce timely and >> complete bug triaging and assignment of triage owners who will >> actually also look at the bugs in their component? >> >> This is an evergreen issue, and as far as I can see, bug triaging is >> still left to chance and the initiative of volunteers ... and >> Benjamin, who's been thrown in at the deep end. >> In reverse order... I've never heard that Benjamin is drowning. Is that incorrect? Second, not all triage is being done by volunteers - Jorg does a ton.  Magnus is doing some.  Kaie also.  Do we have an estimate of what staff are doing? Third, the amount volunteer triage is considerable - I hope we're not saying that needs to disappear. I don't think we can assume the volunteer workload can be replaced by staff hours. Consider this chart, and the work already being done that it represents https://bugzilla.mozilla.org/reports.cgi?product=Thunderbird&datasets=UNCONFIRMED&datasets=NEW&datasets=ASSIGNED&datasets=FIXED&datasets=WORKSFORME Last, this is a community project and so I hope the expectation is that we intentionally develop a model of triage that incorporates all parts of the community. And so, I think maildev is the wrong venue for this discussion. >> Our friends from Mozilla triage their bugs, put them into components, >> You seem to be referring to Mozilla staff, or the Mozilla hired guns. (TBH, I don't know what percentage of their bugs is triaged by volunteers)  But note, anyone can put bugs in components. >> assign priorities P1 to P3, >> ... what's important that only a dev (or an appointed representative) can/should do this. Triaging the backlog is going to be a long process, but does need not to be done by the same person(s) that triage new bugs, or old unconfirmed bugs. But perhaps your point is prioritizing is one of our greatest needs today if we want to be serious about planning, and making that info available to the community via BMO. >> and each component has a triage owner. >> I hope triage owners are also pulled from the community. >> Not so in our project: Looking at new bugs in Thunderbird and >> MailNews Core in the last 300 days, https://mzl.la/2ZStSSP, I see 871 >> bugs, 174 of which are in the untriaged component (20%), so chances >> are the no one has looked at them. >> A deep dive might show your assumption is somewhat off.  To sample a subset I chose the Untriaged component (which might not be representative of the entire UNCO population, hard to say).  When I looked at this several days ago 158 are defects. (I chose defects because most everyone pays no attention to the enh requests, so I exclude them in this specific analysis of "how well we triage".)  Of those, 138 have at least a CC - on 86 bugs I am CC, in 62 I have commented. I sampled 10 of those 62 and *80% are either closable or **(the vast majority) **waiting on reporter. *You have commented in 59, and if factor out the 43 that I have not commented in, then we have 105 bugs touched between us or roughly 2/3 of the list - a significant dent. Conclusion - the fact that many bugs are UNCO in the untriage component doesn't mean they are untouched or didn't get a good look. (And as a side note, perhaps we need only a few more people to fully triage the "Untriaged" component in a more timely fashion.) Looking at your full query several days ago it was 860 bugs. Roughly 600 are defects, of which 377 are still unconfirmed. It may be instructive to sample bugs not in the untriaged component to see if the percentage of actionable bugs is similar to the Untriaged component. Also consider, which components have the most unconfirmed bug reports <https://bugzilla.mozilla.org/report.cgi?x_axis_field=bug_status&y_axis_field=component&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=Client+Software&classification=Components&product=MailNews+Core&product=Thunderbird&resolution=---&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&bug_type=defect&emailtype1=substring&email1=&emailtype2=substring&email2=&emailtype3=substring&email3=&chfield=%5BBug+creation%5D&chfieldvalue=&chfieldfrom=-300d&chfieldto=&j_top=AND&f1=short_desc&o1=nowordssubstr&v1=&f2=component&o2=nowordssubstr&v2=&f3=OP&j3=AND&f4=short_desc&o4=anywordssubstr&v4=&f5=longdesc&o5=anywordssubstr&v5=&f6=CP&format=table&action=wrap>.  Perhaps we focus efforts/manpower and put names where they are most needed. >> Emma took the time to explain all the things Mozilla do with their >> bugs, and although they can't fix all bugs, they at least have a >> system by which someone familiar with the component looks at them and >> takes a decision. Emma also pointed out that looking at enhancement >> requests is important for product planning. She offered her help with >> auto-classifying bugs, etc., but all that help won't help us if we >> don't finally take care of proper triaging. >> >> Let me repeat why proper triaging is necessary: >> >> We need to detect regressions. >> At a superficial level this isn't difficult - most bugs reported in development cycle versions, or the early days of a new release will be regressions (or the typical onslaught of support requests) - if we put manpower into bug reports to those versions or time periods we will largely be successful - in fact the seasoned triager can quickly sense by skimming or looking at the version number whether it is likely a regression. However, finding the regression range often is difficult, and a barrier to getting a bug fixed. So it is not enough to label a bug a regression, we also need competent regression range hunters, who also have time to do the job. OTOH only a small percentage of bug reports are regressions. For example, I looked at three two month periods in the first half of version 60 (filtered on version=60 and unspecified) starting at 2018-08-01, 2018-10-01, and 2018-12-01. In each period roughly 10% of bugs with resolution fixed or open have the regression keyword.  When you include ALL resolutions, a mere 3-5% of bugs have the regression keyword.  In short, to find every regression reported to  bugzilla you are looking for a needle in a haystack, and should expect to expend much manpower unless you are smart about how you find them. >> We need to get a proper feel for buggy components to include >> improvements in the product planning. >> We have 20 years of bug reports - this table <https://bugzilla.mozilla.org/report.cgi?x_axis_field=resolution&y_axis_field=component&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=Client+Software&classification=Components&product=MailNews+Core&product=Thunderbird&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&bug_type=defect&emailtype1=substring&email1=&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=&j_top=AND&f1=short_desc&o1=nowordssubstr&v1=&f2=component&o2=nowordssubstr&v2=&f3=OP&j3=AND&f4=short_desc&o4=anywordssubstr&v4=&f5=longdesc&o5=anywordssubstr&v5=&f6=CP&format=table&action=wrap> should be fairly informative as to where we need to be fixing more, as well as being more proactive in testing, applying (re)engineering efforts and other novel methods to improve stability and reliability. >> We need to collect enhancements for product planning. >> Very true. But how do we do that? Via triage owners(TO)? Or some other mechanism? Perhaps it requires a specific type of triager or TO - consider the 3000+ ENH bugs <https://bugzilla.mozilla.org/report.cgi?x_axis_field=bug_type&y_axis_field=component&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=Client+Software&classification=Components&product=MailNews+Core&product=Thunderbird&resolution=---&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&emailtype1=substring&email1=&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=&j_top=AND&f1=short_desc&o1=nowordssubstr&v1=&f2=component&o2=nowordssubstr&v2=&f3=OP&j3=AND&f4=short_desc&o4=anywordssubstr&v4=&f5=longdesc&o5=anywordssubstr&v5=&f6=CP&format=table&action=wrap> that are in a fair state of disarray (IMO) because most triagers have little or no time for them, or don't care about that category of bug.  I am solidly in both camps - no time and don't care (mostly because of time and therefore whether I care or not is irrelevant), and I suspect most triagers are in this camp. I suggest you only beat down this door by putting people on it who both care (or are forced to) AND have time. >> We need to close duplicates. >> Perhaps. I think it would be interesting to ask why - what is the real goal? This activity tends to take more time than just confirming a (valid) bug - time which for most people might be better spent triaging many other bugs rather than find the duplicate.  In part, because it's only "easy" when you have historical knowledge of the database, or have super-bugzilla-sleuth abilities - both qualities are in *very* short supply. (Even I mark many bugs "dupme", even though I posses both qualities.)   Triage owners or SME (subject matter experts) can help here.  Also some bugzilla training could help address the sleuthing abilities deficiency. >> We need to weed out support requests. >> I think the most important aspect of this is just making sure the user gets to proper support in a caring mannert.  (It's also the cost of doing business to get to "real" bug reports) >> We need to get back to the reporters and give them some answer in a >> semi-timely fashion. >> Out of all the issues you list I would say this should be in the top two, because timely response avoids losing the reporter - and this is one reason why I use bugzilla whines for our most critical bugs - I don't need to look at every bug report, bugzilla tells me which ones to look at.   But not all reports need to be answered within 1-2 days.  I speculate answering in 7-10 days is fine for most bug reports. >> And we might even see some bugs that can be fixed more or less "on >> the spot" without having to include them in the big planning scheme. >> I don't understand this point. Can you elaborate? Are you referring to regressions? If you're not, then we're in the boat of "not all bugs are created equal". Plus, at least presently, we don't have the manpower to fix every reported regression - unless priorities are changed.