Issue Management, Tags, and Quantified Task Management

On our Discourse community, we use Quantified Task Management (QTM) to organize and prioritize issues. We also have a number of other tags for categorizing issues.

All four QTM measures: Gravity, Priority, Friction, and Relativity are represented as tags. All @moderators and @contributors can add QTM tags to bug reports, feature requests, and the like.

Many tags have synonyms, so you don’t have to memorize names. For example, #g5 and #critical will both map to #critical when applied to a topic.


All five “issue” categories allow for voting. Users can cast their votes for any bug, feature suggestion, or other issue. This should be encouraged instead of posting “+1” type responses.

All the issue categories sort by votes by default, so the highest voted issues rise to the top.


Status tags allow us to track which issues have been picked up.

  • #accepted : We have confirmed this issue, and will work on it at some point.
  • #candidate : We are considering this issue, but haven’t decided yet.
  • #declined : We have decided not to work on this issue.
  • #for-plugin : We (probably) aren’t going to address this issue directly, but it would make a good plugin.
  • #invalid : This issue was found not to exist.
  • #needs-reproduction : We need someone else to confirm this exists before we can work on it.
  • #stale: We never got the information necessary to resolve this.
  • #resolved : We did it! :tada:
  • #resolved-plugin: This feature was implemented with a plugin. :tada:

There are several more tags for classifying the issue.

  • #busywork : This is an issue that mainly consists of slogging through a simple and repetitive task.
  • #help-wanted : We are looking for some help on this task.
  • #incomplete: This issue needs more details.
  • #possible-duplicate: Might be a duplicate of another issue, but hasn’t yet been confirmed as such.
  • #not-us : We can’t do anything about this issue; it relates to another project or service, and is out of our hands.
  • #spooky : This issue is resisting reproduction, diagnosis, and/or fixing.

Merging Duplicates

If one issue is a duplicate of another, you can merge it into the main topic. Click the Wrench, Select Messages, select all, and Move To the main topic in question. If you move all the posts in the topic at once, the previous topic will automatically be closed.

In the Move To window, be sure to select the radio button to the left of the topic title, and NOT on the topic title itself. There’s a bit of a glitch, where clicking the title just jumps to that topic without doing anything.

“Resolved” Subcategory

When an issue is “resolved” — namely, tagged #resolved, or #invalid — it can be moved to the Resolved subcategory of the topic’s main category. This does five things:

  1. It removes the issue (topic) from the main category, so only active issues are visible there.

  2. It releases previous votes on the issue so users can use those votes elsewhere. (Votes are still remembered behind-the-scenes, and are restored if the topic is moved out of Resolved again.)

  3. Users who voted for the issue are notified that the issue is closed, and that their votes have been released.

  4. It reduces the search precedence, thereby encouraging new issues to be created rather than old threads hijacked.

  5. It automatically closes the topic 30 days from the last post. (Used to be shorter, but this way, folks can report regressions or dispute wrong closures more easily.


This measures how important a task is.

  • #critical / #g5 : Related to essential or core functionality. Should never include aesthetic and convenience functionality. (However, this may indicate a bug that breaks an existing major feature.)
  • #significant / #g4 : Must be completed, only cut if desperate. Includes only functional requirements which directly improve on g5 features. (No bells-and-whistles.)
  • #major / #g3 : Non-essential, but should be completed if time permits. “Polishing” tasks, and the most important bells-and-whistles.
  • #minor / #g2 : Nice feature to have, will probably work on this at some point.
  • #trivial / #g1 : “Would be nice” tasks; these take backseat to the completion of all other tasks. Should contain only tasks that could reasonably belong in the project at some point .
  • #wishlist / #g0 : All other tasks which have been properly discussed, but no higher Gravity rating could be determined.

If no Gravity has been determined (Triage), don’t apply a gravity tag.


How soon the task should be completed.

  • #immediate / #p5 : Emergency. The server caught fire. :fire: :fire_engine:
  • #next / #p4 : Slated for the current development cycle, especially the next release.
  • #soon / #p3 : Will try to get it in the current development cycle, but likely will be in a later cycle.
  • #later / #p2 : Slated for a later development cycle, unless we have spare time in the current cycle.
  • #eventual / #p1 : While we want to work on this, it isn’t slated for an upcoming development cycle.


This is really intended as a measure of how many available resources there are for completing the task, as a way of measuring relative difficulty. We’ve simplified this in our QTM implementation.

  • #low-hanging-fruit / #f0 / #f1 : Good task for a beginner.
  • #casual / #f2 : Relatively easy task if you’re familiar with Mailspring.
  • #intermediate / #f3 : Requires some effort, but still reasonably possible with the relevant documentation and code.
  • #hard-mode / #f4 / #f5 : Really hard. Involves hard-core research and experimentation.


“Flux” is any unknown factor in a task: an unfamiliar library, an unsolved problem in the platform, an undocumented process, etc. A “black hole” is a task which defies all attempts to complete it. The more flux a task has, the more likely it is a black hole. Too much flux, and it will actually be impossible to ever complete a task, at which point it must be reevaluated.

This also has been adapted slightly for our implementation.

  • #straightforward / #r0 / #r1 : Little to no flux. Unlikely to be a black hole.
  • #tricky / #r2 / #r3 : Contains some flux; possible black hole. Hard to estimate effort and time.
  • #black-hole / #r4 : Extensive flux; definite black hole. Not possible to set end date.
  • #impossible / #r5 : Literally impossible to complete as-is. Must be refactored or reevaluated to continue.