Sifter is designed heavily around accountability. In fact, it’s so key that it’s the primary element of the navigation menus. 1 However, we know that you don’t always know the assignee for a given issue at the moment that it’s created. So with each project, you can select up to 10 people that will receive a notification whenever an issue is left unassigned.

The navigation shows three main options, 'Mine', 'Unassigned', and 'Everyone's' — 1 Accountability is designed into almost every corner of Sifter.

We suggest limiting that to 2 or 3, but you can have up to 10 if you’d like. The reason behind limiting the number of unassigned issue notifications is that the more people you have, the more likely you are to run into a case of “someone else will take care of it.” Everybody’s busy, and it’s easy for someone to think they can skip this one issue and let someone else handle it if they think there’s a large group of people to potentially address it. This can actually dilute accountability be counter-productive. This is just a small case where more isn’t necessarily merrier.

The fact that an issue is unassigned is designed to standout. — 2 If an issue is unassigned, Sifter constantly reminds you of the void waiting to be filled.

Additionally, Sifter considers unassigned issues to be a red flag and treats the meta data accordingly by making it red. 2 It’s just one more subtle way that Sifter helps encourage issues to move towards being assigned.

How does it work?

Assuming that you’re an administrator, you can visit the “Notifications” section under “Project Settings”. 3 You’ll see a list of all available team members for the project. You can select up to 10 at a time, and we’ll add them to the notification list for new unassigned issues.

A list of checkboxes of available team members that can receive unassigned issue notifications. — 3 Administrators can setup team members that should be notified when issues are left unassigned.

How can this help?

If you can assign an issue as soon as it’s created, that’s great. However, many times, the person opening the issue doesn’t know who the assignee should be. In those cases, you can setup the project managers or team leads to receive unassigned issue notifications. That way, the issue opener doesn’t need to worry about it. Sifter will notify the designtated people so that they can assign the issue to the best person for the job. That means less burden on folks opening issues and hopefully more time to capture more issues.

Unassigned Issues in Workflow

Without an assignee, it’s possible that an issue may slip through the cracks, but within Sifter, unassigned issues are designed to standout. From both our dashboard 4 and our navigation, unassigned issue counts are always readily visible. Add this to unassigned issue notifications, and it’s pretty hard to accidentally overlook these issues.

Each project is a row with numbers for each of the assignees: mine, unassigned, everyone's. — 4 The dashboard overview makes it easy to quickly identify projects with unassigned issues.

From a planning standpoint, unassigned issues in milestones 5 can also serve to provide an extra facet to provide insight to how a milestone is going. Too many unassigned issues, and it can be a red flag that some prioritization and assignment needs to happen to keep thigns moving forward.

Each milestone is a row with a progress bar and numbers for each of the assignees: mine, unassigned, everyone's. — 5 The milestones overview can help identify unassigned issues that may be blocking progress.

Since there’s no reason to fear unassigned issues, let’s embrace them. By accepting unassigned issues into your workflow, it’s possible to use assignment as a sort of implicit “accepted” state. A lot of teams prefer that issues are explicitly accepted prior to developers beginning work on the issue. This way, you can simply wait to assign issues until after they’ve been reviewed and accepted. Then, once they have an assignee, they’re implicitly considered in progress.