Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
DeepTriage: Exploring the Effectiveness of Deep Learning for Bug Triaging (mybluemix.net)
94 points by lainon on Jan 8, 2018 | hide | past | favorite | 7 comments


this is not what i thought it was

the term "triage" means to order items (patients, originally) according to urgency

this paper has nothing whatever to do with sorting a bug list according to urgency

the paper describes a model to assign a particular bug to the developer who can resolve it most efficiently

to me this is "assignment" not "triaging"

but at least you can see how a supervised learning technique is a good fit for the problem they actually describe

so one row in the training set is a set of attributes relating to the bug itself--where in the codebase it resides, etc

the class labels are of course the developers assigned to fix the bug

what actually is presented in this paper might be useful--although i have my doubts that the net value of such a model (optimum assignment of devs to bugs). In other words, even if the model can generate assignments better and more efficiently than manual assignment, the developer time required to write the code to convert the raw data to model input (to train/test/validate the model) is not small--for intance, look at how much unstructured text is involved

i doubt i would go to the trouble--mapping devs to bugs is nothing something we do poorly at my shop, and even when i get it wrong, the devs sort it out by swaping out tickets

not nearly as useful as an automated bug triaging sytem--ie, a system that would auto-sort our bug list based on urgency, but again, that's not the subject of this paper, title notwithstanding.


In large teams with a large number of microsoervices, triage is about assigning bugs to teams (and therefore devs) because those who file them (and most of the devs) don't know what service is affected by the bug. That and de-duping of course.


It's better to just assign it at the closest to user facing level first and then let teams pass it down to their part's dependencies as and when it's required.

There are often bugs which could be fixed in different systems by different teams and by assigning it directly to one team without the communication involved in passing it down it could end up being 'fixed' in an architecturally damaging way.


Since there doesn't appear to be a link to the paper: https://arxiv.org/abs/1801.01275


I wonder if a system like this were used in the real world, it might simply end up behaving as a hashing algorithm, always assigning the same category of bug to the same developer - who would become skilled in handling this type of bug and provide confirmation that the system was functioning correctly. ( Obviously I appreciate that this isn't how the system is trained initially ).


It seems it doesn't take into account developers' commit. I wonder if doing that would help. Right now ~50% accuracy for rank-10 doesn't seem to be too useful in practice.


This is really interesting. Given how open most development tools are and the fact that users will constantly generate data makes them a natural environment for deep learning based productivity plugins. But we can't have nice things :( -- also this doesn't sound like a great way to make money.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: