Does anybody have experience with using a bug-tracking / issue-tracking software like bugzilla, mantis or JIRA not only for bugs or tasks, but to initiate and maintain discussions that in the end lead to a decision?For example, a developer thinks that all protected fields should be abolished and changed to private fields with protected methods that access them. It is not his call, and he would like to discuss it. Normally he brings up the point in the next developer meeting at the end of which a decision is made. Instead, my idea was for him to open an issue of a certain type decision and describe his intent like normally one would describe a bug or task.Other developers can make their comments if they feel like it, and in the end, the issue is closed as accepted or denied.The advantages I see in this:Asynchronous communication: no one is forced to voice his opinion in a meeting when they didn't have time yet to oversee all ramifications of said decision.Written log of considerations that lead to a decision. If one later raises that question again he can be referred to it.Relations to other issues can be made, e.g. a task can be followed back to a decision.Integration with version control software, e.g. a commit can be traced back to a decision.Disadvantages:Heavy smell of a golden hammer: issue tracking software normally is used to track actionable itemsOrganizational overhead may be disproportionate: instead of a small informal talk one has to communicate his ideas in written form
Using bug-tracking / issue-tracking software to discuss design questions, new tools etc
development process;tools;issue tracking
The way we work, issue tracking should track all issues. We don't know what issues are actionable until it has been analyzed. If the tracking system only has actionable issues in it, it is likely they are being triaged too soon, meaning any discussions and decision is lost. We take the approach every thing should go in (In our workflow anyway), as otherwise issues can be repeatably raised with no visibility. We have a category in our Jira implementation for Risk, so we are using Jira to track items that are not actionable, but have the ability to jeopardize the software in some way. Discussion on the item is tracked and once the risk is gone (or mitigated) the issue is closed. The example you have given could easily go into the Risk category. It is important that things such as this are discussed and tracked, and the decision recorded. When the developer re-raises the issue in a few months time, the Asked and answered response has a justification to it. 