<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Hi Tamas,
<div class=""><br class="">
</div>
<div class="">Thanks for highlighting this - it shows that at least we should have a description of what it means for a bug to be assigned to someone. Your interpretation of a bug being “locked” doesn’t sound unreasonable to me without any other description
being available.</div>
<div class=""><br class="">
</div>
<div class="">For the clang static analyser component, it is configured in bugzilla that when a new bug is raised against it, there is a default assignee. My guess is that most bugs reported against that component just keep on having that default assignee.</div>
<div class="">I think it’d be an improvement to move default assignees (for the components that have them) to the “default cc” list. That way, the same people still get notified when a bug is raised, but bugs don’t get automatically assigned to them. It’ll
take an actual conscious action to assign a bug - so hopefully a bug being assigned to someone can become more meaningful. Or in short, a setup that is somewhat similar to what you describe the LibreOffice project has indeed seems better.</div>
<div class=""><br class="">
</div>
<div class="">Thanks!</div>
<div class=""><br class="">
</div>
<div class="">Kristof</div>
<div class=""><br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 6 Oct 2018, at 22:53, Tamás Zolnai <<a href="mailto:zolnaitamas2000@gmail.com" class="">zolnaitamas2000@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">
<div dir="ltr" class="">Hi all,
<div class=""><br class="">
</div>
<div class="">Just a short feedback about my first impression of the llvm bugzilla. I just requested an account for bugzilla and I just did some browsing the bugs. I checked static analyzer related bugs and as I see almost all bugs are assigned, which is a
bit strange to me. Also most of the assigned bugs were assigned to two assignees, so I expect that these two people don't actually work on that ~600 bugs.</div>
<div class=""><br class="">
</div>
<div class="">So I'm a bit confused now what assigning means in llvm bugzilla. In general for me assigning means the bug is "locked", somebody is working on that issue, so I should not pick it up for working on it. Which means that by now almost every static
analyzer related bugs are locked in bugzilla, so I need to find a task somewhere else.</div>
<div class=""><br class="">
</div>
<div class="">In LibreOffice project we also use bugzilla and only assign a bug if the assignee is actually working on that issue or he/she is planning to work on it soon. Also we reset assignee back to "non" after some months of inactivity. Which means that
most of the bugs are unassinged so new contributors can pick them up (also can filter for unassigned bugs). If a bug is related to an area which has an "owner" or expert, we add the expert to the "CC" list so he/she get notified.</div>
<div class=""><br class="">
</div>
<div class="">I did not find any information about that what assigning means in llvm bugzilla, so I don't know whether it have a different meaning what I expected and described above.</div>
<div class=""><br class="">
</div>
<div class="">Best Regards,</div>
<div class="">Tamás Zolnai</div>
<div class=""><br class="">
</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="">Kristof Beyls via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> ezt írta (időpont: 2018. okt. 4., Cs, 11:55):<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word;line-break:after-white-space" class=""><span class="">Hi all,</span><br class="">
<div class=""><font color="#5856d6" class=""><span class=""><br class="">
</span></font><span class="">I’d like to share a few thoughts and analysis results on the LLVM bug life cycle, especially the reporting/triaging part.</span><br class="">
<font color="#5856d6" class=""><span class=""><br class="">
</span></font><span class="">As one of the few people creating llvm bugzilla accounts when people request an account, I started to have a feel that many reported bugs, especially by first-time reporters, never get any reply or feedback, let alone be acted on.</span><br class="">
<span class="">If people go through the effort of requesting an account, and then reporting the bug, they show motivation to contribute to the project. However, if then they see zero return on their effort spent, even if it’s just a confirmation of the bug
indeed being real or an explanation of what they thought to be a bug isn’t actually a bug, I fear as a community we disincentify a large number of potential long-term contributors.</span><br class="">
<font color="#5856d6" class=""><span class=""><br class="">
</span></font><span class="">The above was all based on gut feel, so I tried to gather a bit more data to see if my feel was correct or not.</span><br class="">
<span class="">I scraped the bugs in bugzilla and post-processed them a bit. Below is a chart showing, year by year, how long it takes for a reported bug to get any comment from anyone besides to original reporter. If the bug is still open and didn’t have any
reaction after half a year the chart categorizes is as an “infinite” response time.</span><br class="">
<font color="#5856d6" class=""><span class=""><br class="">
</span></font><span class=""> </span><img id="m_7715599912933527487m_5266135559379465777m_-7013002737400607865m_33407702869735875321E93BF73-F898-4729-A715-C867EEC4BD29" class=""><br class="">
<span class="">It shows that in recent years the chance of never getting a response to a bug report has been increasing.</span><br class="">
<span class="">For some bugs - e.g. an experienced LLVM developer records a not-that-important bug in bugzilla - that may be just fine.</span><br class="">
<span class="">However, I assume that for people reporting a bug for the first time, the majority may look at least for confirmation that what they reported is actually a bug.</span><br class="">
<span class="">The chart shows (blue bars) that about 50% of first-time bug reporters never get any reply.</span><br class="">
<font color="#5856d6" class=""><span class=""><br class="">
</span></font><span class="">I also plotted which components get the most reported bugs that don’t get any reaction and remain open:</span><br class="">
<img id="m_7715599912933527487m_5266135559379465777m_-7013002737400607865m_3340770286973587532497C62EB-AA6C-41CE-9C59-E3738B9451FD" class=""><br class="">
<span class="">The percentage at the top of the bars is the percentage of bugs against that component that never get any reaction. The bar height shows the absolute numbers.</span><br class="">
<font color="#5856d6" class=""><br class="">
<span class=""><br class="">
</span></font><span class="">I hope that at the “Lifecycle of LLVM bug reports” BoF at the upcoming dev meeting in San Jose (</span><a href="https://llvmdev18.sched.com/event/H2T3" target="_blank" class="">https://llvmdev18.sched.com/event/H2T3</a><span class="">,
17th of October, 10.30am), we can discuss what could be done to improve the experience for first-time reporters and also to reduce the number of bug reports that seemingly get ignored completely.</span><br class="">
<span class="">By sending this email, I hope to trigger discussion before the BoF, both by attendees and non-attendees, so that we have a more fruitful outcome.</span><br class="">
<font color="#5856d6" class=""><span class=""><br class="">
</span></font><span class="">At first sight, to me, it seems that the following actions would help:</span><br class="">
<ul class="">
<li class=""><span class="">Let’s introduce some form of “triaged” state in bugzilla, to represent that a bug report has been accepted as describing a real problem; able to be acted on (e.g. has a suitable reproducer); and not being a duplicate of another bug
report. Looking at </span><a href="https://bugzilla.readthedocs.io/en/5.0/using/editing.html#life-cycle-of-a-bug" target="_blank" class="">https://bugzilla.readthedocs.io/en/5.0/using/editing.html#life-cycle-of-a-bug</a><span class="">, maybe the best way
to achieve this would be for newly raised bugs to by default go to an “UNCONFIRMED” state instead of “NEW”? Moving the status to “NEW” or “CONFIRMED” would indicate the bug has been triaged.</span></li><li class=""><span class="">Would it help to have one or multiple people per component that volunteer to triage new bugs?</span></li><li class=""><span class="">With the majority of developers being part of a team working on a product based on LLVM, I would assume that it is in the interest of most that reported bugs at least get evaluated/triaged? What is stopping those developers to find
the time to do some triaging? Would a better notification mechanism be useful to notify when new bugs on a specific component come in that you could triage? Maybe per component try to have a few people on the “default CC list”, which seems easy to set up as
a bugzilla administrator.</span></li><li class=""><span class="">Should we get rid of the "new-bugs/new bugs” component if we won’t have people triaging them?</span></li><li class=""><span class="">Should we have some description of what a reasonable triage of a bug looks like?
</span><span class="">If we write such a page, we could also use that page to describe what we think should get recorded when closing bugs.</span></li></ul>
<font color="#5856d6" class=""><span class=""><br class="">
</span></font><span class="">Thanks,</span><br class="">
<font color="#5856d6" class=""><span class=""><br class="">
</span></font><span class="">Kristof</span></div>
<br class="">
</div>
_______________________________________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>