Using bug-tracking / issue-tracking software to discuss design questions, new tools etc

Question

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 items
• Organizational overhead may be disproportionate: instead of a small informal talk one has to communicate his ideas in written form

Answer 1

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.

Answer 2

Correct me if i am wrong; but i think what you are talking about it is - "Can/How to use Bug tracking/Issue Tracking systems to also do 'Decision Tracking'. Is it or am i missing something?

At the outset i would say this is indeed a great idea. Though we don't use it in the exact said manner, it makes sense that we use it for the purpose of tracking. In our case, a long thread of email - more as a forum/mailing list is followed.

However, your question in a broader sense is about how to make (and manage) decisions effectively and connect the implications of work back to decisions taken that brings better insights.

As i said, it can be great a idea if that helps people. Nothing wrong about it. But for effectively making/manging decisions needs few concrete things.

1. It is true that most decisions should be broad based inclusive effort so that all important aspects are covered and weighed appropriately before decisions are based. So whatever tool you use must have enabled transparent access to information to all concerned. You are right that Asynchronous mode of conveying and collecting information helps because people can put in time before putting suggestions. If asked for upfront answers - typically in the meetings, the judgment might not be equally sound compared to the same person with enough homework.

2. However, this doesn't necessarily mean "pure democracy" where every vote is equal. In general, the decision making person should be one or few - and while they have taken all opinions, they must be individually responsible for the decisions and not all people who provided their opinions.

3. Most decisions must be actionable. This might find hard to avoid contradictions; but the fact that decisions are not actionable and only subjective means there possibilities for future (mis)interpretations.

4. It is important to classify the level and scope of the decision. Most importantly we must identify whether are we discussing specific design problem or specific aspect of code, aspect of processes or are these project planning and tracking related issues? Quite often when issues strike from a production code - all of these are applicable, but we must be able to distinguish all different aspects and independently to be able to manage these decisions effectively.

5. Sometimes the decisions could be of whether we use certain systems or roles and responsibilities for individuals; it might be harsh to put these decisions along side with coding specific decisions on a notice-board-type forum.

6. Just an additional anecdotes; every team must put code reviews and design reviews as a process by itself - which will exhaustively cover many issues the likes of example you quoted. They are must whether or not decisions tracking deals with other things or not.

A good decision making practices involve a lot of discipline on how we pull the information together and ensuring that decisions are followed through with the implementations with the right spirit.

A tool can only help to make information more presentable not beyond that; but that might be good help if it works for you.

Answer 3

FogBugz is the way to go. It's not free. The newest features make implementing an agile methodology even easier.

A simpler, free way to go would be Asana.

No matter what tool you use, team communication is the most important to facilitate a successful project.