More often than not, when people ask for notifications, they ask for something along the lines of a way to notify multiple people about an issue or comment. Traditionally these are lists of names with a checkbox next to each name. They might include a way to notify groups of people as well. This is great for broadcasting team announcements or other information, but it’s not so great for issue tracking.
Lack of Discretion
It’s an unfortunate truth that, in the context of an issue tracker, there are those that believe that notifying the entire team is the best decision in order to get their issue addressed faster. Of course, for those on the receiving end, this has negative consequences as people begin to ignore emails from certain people or even ignore notifications entirely if it gets to be too noisy.
Signal vs. Noise in General
Even without notifying the whole team, a few extra notifications here and there eventually add up. As a result, you end up with a few too many emails, and now you’re less confident about whether each notification is relevant. It’s a slippery slope, and before you know it, people aren’t taking the notifications seriously.
Auto-subscribing Others
We also want to avoid enabling people to auto-subscribe others. Nobody knows better whether you should receive endless updates about a specific issue than you do. We’re exploring ways for people to do a one-time notification about a specific issue without auto-subscribing the recipient. Then, we’ll leave it up to the recipient whether they should be a part of the conversation going forward. We’re even working on a way for people to begin unsubscribing from notifications for an issue after they’re not longer involved with that conversation.
Broadcasting Notifications vs. Assigning Responsibility
Sifter is not a project management tool. It’s intentionally not designed to broadcast announcements to a group of people. It’s designed to assign responsibility to an individual and then move that responsibility around as necessary until an issue is resolved and ultimately closed. With one, selecting many recipients is important, with the other, it’s a distraction. Once an issue has been assigned to someone, it’s up to that person to decide if they need support in resolving the issue. To that end, we’re working on a feature that will then enable the assignee, and maybe a select few other people to easily notify a select group of people about an issue and ask for their opinion. These notifications will explicitly be designed to be different from the traditional update notifications so that people can file and respond to them accordingly.
Accountability
Even with a single assignee, when an issue is sent to half a dozen people, it’s incredibly easy, even tempting, to put it off until the other people have chimed in. By ensuring that a new issue has only one accountable person and that nobody else is notified, the burden of responsibility is firmly on the assignee. There’s no passing the buck or thinking someone else was going to do something first. The result is that things get done faster. As we mentioned before, we’ll be making it even easier for assignees to quickly ping other team members with a one-time notification asking for their input.
“Just one more field…”
Adding additional fields to issue creation forms is dangerous. On the surface, it’s always just one more field. However, it’s a slippery slope. In this case, adding a list of checkboxes, a rather large list in some cases, is just that much more cognitive overload for an already tedious task. Sifter is designed so that you can fire and forget. Even if you leave an issue unassigned, we expose it in the interface so that it doesn’t get lost. Fewer fields means more issues captured. That’s always a win.
Summary
Sifter isn’t perfect with notifications, but we’re working on it. Literally, we’re working on it right now. We’ve been sorting through three years of customer feedback about notifications, and we have some great ideas. The above factors will definitely be informing the design of those ideas. We only ever want to make improvements that increase the quality of Sifter’s email notifications. The side effect may mean that it’s not quite as easy to notify the whole team, but in our experience, that’s a feature, not a drawback.