2016-02-29 - bugtracking at scale

since some time i work in a project that is part of a much larger system. in reality it means it is not uncommon to have a problem report from testers, that takes days-to-weeks to fix, and spans multiple system components, and different locations. often it means you're added into a middle of some ongoing discussion, that goes on and for 10s of pages. it's hard to get up to speed quickly here, and filter “findings” that turned out to be inaccurate from the ones that are currently main subjects.

i recently came to a conclusion bugtracker could be amended to support two tabs: discussion (forum-like) and facts (wiki). on forum ppl cloud just put in what they think, ask questions, loop other is, etc… business as usual. whenever something relevant has been found – like an important part of log, or interesting fact about particular test setup – it would be then put on “facts” tab, so that when a new person is added to a discussion, she can skip all the discussion and just go through “facts” to see what's up and what to do next.

an interesting side effect would be a nice option for analyzing historical bugs. if you need to know what was the bug's reason, how it was located and what caused it, you just open one, short page with all the important pieces of information and you're good. no need to look for old @s (which you may not have even participated in, in a first place!) and reading through 30 pages of free-form text, to find 3 relevant sentences.

now having such a “facts” page organized in a computer-readable fashion would help to do data mining. this way system could, in theory, try to correlate typical scenarios with historical issues. for instance having similar parts of logs marked as relevant in two problem reports, could directly point out similar issue and direct ppl towards a solution (if the problem is known) or right subsystem (if the problem is new, but similar to the one already processed). it would probably do a good job at detecting duplicates as well.