Our philosophy is that in order to create the best software possible, all of these people need to work together. We had years of experience using bug trackers that are awesome for developers, but when it came to non-technical team members, they weren’t quite so inviting. Clients, designers, and other less technically inclined people were intimidated by all of the options and process. As a result, they had problems learning the system, participated less, and in some cases, avoided it entirely. If your bug and issue tracker is purely for tracking bugs and doesn’t need wide participation, that’s not a bad thing, but these days, with smaller integrated teams accomplishing larger things, that’s not always the case.
Every decision that we make revolves around giving equal consideration to both technical and non-technical team members. That usually means putting fancy developer-friendly features on the back burner. We want Sifter to be inviting and welcoming for everyone. The unfortunate side effect is that Sifter doesn’t exactly kick ass in terms of developer-friendly features, yet. Eventually we’ll improve, but for the time being, we’re comfortable with that tradeoff as we focus on building a tool that the whole team is comfortable using.
None of this is to say the other issue tracking options out there are bad, they just aren’t right for everyone. Just as Sifter would never work for a huge deeply technical team, those other apps are overkill for small integrated teams. Whenever we get an email where it’s clear that Sifter won’t be a good fit, we’ll send them a list of half a dozen alternatives that we think may be a better fit for their needs. We get a lot of questions about why Sifter does or doesn’t do some more developer friendly things, and this decision is the underlying reason. We’ll get there, but we have some other things we need to take care of first.