File Upload Size Limit
Currently, Sifter limits attachments to 5 per issue or comment at 10mb each. We actually feel like that’s a bit generous. Sifter isn’t meant to be a file-sharing or document-storing tool. So, we view attachments as meta-data. That is, the attachments should be secondary to the subject. Chances are that if someone wants to upload a file larger than that, it doesn’t belong in Sifter. A smaller, more detailed, file would usually be better. Similarly, if you need to upload more than 5 files for an issue, there’s a strong chance that you should consider splitting it out into multiple issues.
Changing these limits is almost trivial from a technical standpoint. It might slow things down, but that’s the least of our concerns. While a pure engineering viewpoint might focus on whether it could be done, we’re more interested in whether it should be done. It’s easy to give people more power than they could ever need, but we think it’s better to give them just what they need and no more.
CC’ing People on Issue Creation
We also regularly receive requests from people who would like to notify more than just the assignee when an issue is created. They usually suggest something like the way that Basecamp handles notifications. However, Sifter is very different from Basecamp. The former is for tracking and resolving discrete issues while the latter is more for distributing information among a group of people.
In Sifter, we have two reasons for not providing this feature. The first is that Sifter is about discrete accountability. If you have multiple recipients, it’s much easier to think “someone else will take care of that”. However, if you know that there’s always only one recipient and it’s you, you’re going to be much more likely to reassign it when it’s incorrectly assigned or not relevant.
The second reason is simply that we all receive more than enough email these days. By limiting email from Sifter to only those issues that you are explicitly involved with, you can always rest assured that any email in your inbox from Sifter represents an issue for which you have some level of responsibility.
This approach doesn’t work for everyone, but we feel that it’s much better to err on the side of fewer and more likely to be important emails than more emails of which many are likely to be irrelevant. We want a high signal to noise ratio, so we’ve designed Sifter to emphasize that.
Time Tracking
Finally, it seems time tracking has been a hot topic of late. Nobody has really asked for it, but we get lots of questions about whether it’s on our radar. It’s not. While we recognize the value of time tracking for some companies, we know that it’s not important for all companies that use Sifter. Either they already have a good time tracking solution, they require their time tracking to integrate with their billing software, or they simply aren’t interested in time tracking. As a result, there aren’t enough Sifter customers to justify us diverting development hours towards time tracking.
In addition to that, the only advantage that Sifter could provide with time tracking is the ability to track the work at a micro (i.e. bug and issue) level instead of a macro (i.e. project and client) level. However, we feel that for most scenarios, that’s just too detailed. Accounting usually bills on a project or client level, and time doesn’t always correspond neatly to a specific bug or issue.
Sure we could spend time on time tracking, but that’s not our specialty. As a result, we’d do an inferior job relative to the slew of great time tracking options out there. Some day, when we run out of ways to improve the issue tracking aspects of Sifter, we might reconsider, but that’s a long ways off.
Summary
We rarely think about whether we could do something because it’s much more likely that we’d decide that we shouldn’t do it. We go out of our way to not only answer questions with yes or no but to also go into detail about why we’ve made the decisions that we’ve made. It’s much more difficult to think about the social implications of features, but we think that designing to discourage particular uses, is just as important as designing to encourage particular uses.