diff options
Diffstat (limited to 'sifterapp/choosing-bug-tracker.txt')
| -rw-r--r-- | sifterapp/choosing-bug-tracker.txt | 16 |
1 files changed, 16 insertions, 0 deletions
diff --git a/sifterapp/choosing-bug-tracker.txt b/sifterapp/choosing-bug-tracker.txt new file mode 100644 index 0000000..7837b65 --- /dev/null +++ b/sifterapp/choosing-bug-tracker.txt @@ -0,0 +1,16 @@ + +> I just had another idea inspired by this. “Why it’s so difficult for your team to settle on a bug tracker?” +> +> The premise is the Goldilocks story. This bug tracker is too simple. This bug tracker is too complicated. This bug tracker is just right. +> +> Effectively, with bug and issue trackers, there’s a spectrum. On one end, you have todo lists/spreadsheets. Then you have things like GitHub Issues/Sifter/Trello somewhere in the middle, and then Jira/Fogbugz/etc. all of the way to the other end. +> +> Each of these tools makes tradeoffs. With Sifter, we keep it simple so small teams can actually have bug tracking because for them, they’d just as soon have no bug tracking as use Jira. It’s way too complicated for them. +> +> Other teams doing really complex things find Sifter laughably simple. Their complexity needs justify the investment in training and excluding non-technical users. +> +> This is all complicated by the fact that teams inevitably want ease-of-use and powerful customization, which, while not inherently exclusive of each other, are generally at odds with each other. +> +> To make matters worse, on a larger team, some portion of the team values simplicity more while other parts of the team value advanced configuration and control. Neither group is wrong, but it is incredibly difficult to find a tool with the balance that’s right for a team. +> +> I could probably expand on this more, but that should be enough to see if you think it’s a good topic or not. |