Rethinking JIRA watches

When your project grows beyond just a small project group you will soon se the need to be notified when issues change, even more if your project is international, with team members in different locations and perhaps even different time zones.

JIRA can help you with this. You can easily set up Jira to send you email when issues change, in fact Jira default setup probably means you will get a lot of emails.

Notifications part 1 : watchers

JIRA notification feature really has two parts. The first part, watchers is visible to everyone in the issue page:

If you are watching the issue there will be a link that says 'Stop watching this issue'  like in this screen dump, if you are not the link will say 'Watch this issue' . Any case it will work as expected and turn your watching on or off. 

There is also a little badge that shows current number of watchers.  If you click it you will eventually get a little popup where you can add or remove watchers, yourself or another user.

The watch is an on/off switch. You cannot select what changes to the issue you want to watch. Most likely you will get a lot of emails when you watch an issue. 

And if you think you are getting too many emails and try clicking 'Stop watching this issue' you might still be getting those emails That's because of the second part

Notifications part 2 : the scheme

What really determines when notification emails are sent is the notification scheme. Unlike the watchers you can't really see this in the issue screen, and a JIRA user might not even know that it is there, since they do not have access to it.

Jira comes with a default notification scheme, which looks like these two screenshots:

Notification scheme part 1

As you can see here, watchers is only part of it, you might also get emails because you reported the issue or because you are the current assignee.

A user cannot do anything about those, Even if you click 'Stop watching this issue' you will still get them.

And very likely your JIRA administrator cannot remove them either, because that would affect other users.

There is a lot more a good JIRA expert can do with the notification scheme, but since rules are the same for all issues and users you cannot really control the number of notifications sent to you.

Notification scheme part 2

The notification scheme is big, there is a lot of events you can use. If you want to you can have different rules when a comment is added and when its edited and different rules for 'Work logged', 'Work started' and 'Work stopped' for example.

But still its not fine grained enough. While there are separate events for some status changes (Created, Resolved, Closed, Reopened) there are not any events for other statuses that might be more important for your role in your workflow. When we tested those they ended up in the last one on the list, 'GenericEvent' , which is not easy for a user to know.

And there is one event for all updates, so there is no possibility to avoid updates that only affects fields you really don't want a notification for.

Conclusion

JIRA is very good at sending out email notifications, in fact many would say that it sends too many notifications. The watch/unwatch mechanism is easy to understand, but often gives you too many notifications. The notification scheme is very powerful, but hidden for most users, so they do not have control over what emails they get. Events are many, but not always easy to understand, sometimes not fine-grained enough and not available for the user to use.

This is why we developed Smartwatch for JIRA, a plugin that puts the user in control of notifications, realizing that

• users are different, they have different roles and preferences, so they want watches to work differently
• issues are different. Some needs careful monitoring and you want to follow everything, some are not so critical, but you still want to know when they are ready