This is the initial assessment of an issue. The purpose is to get
it moving in the right direction and make sure it gets noticed in
the right context, which means making sure that every issue has a
suitable category and version. New issues are reported all the
time, sometimes the submitter fills in fields, sometimes not.
That cannot be controlled. Everything else can.
Move the issue to the correct project. Sometimes an issue is
reported as a Taskserver bug, but it is a sync issue with
Move the issue to the correct type, which means bug, feature
or improvement. Sometimes it is not easy to distinguish, and
some folks are clever about reporting a feature request in
the form of a bug, assuming that bugs gets more attention
than feature requests. We're not fooled by that.
All bugs should have the "Target version" set to the current
development effort. This reflects the need to fix as many bugs
in a release as practical because bugs are a priority.
The "To" field should be blank. This indicates that no one is
currently working on it.
"Category" is usually set to "core" unless there is a more
"Priority" should be "Normal" unless the bug causes crashes,
lack of functionality, or the worst possible: data corruption.
Whatever the submitter sets priority to, reassess it, because
it will not influence anything. Only the true nature of the
bug influences priority.
"Status" should stay as "New".
"Due date", nope. We don't work that way.
"Target version" has only two alternatives. Either it is a
Taskwarrior bug in which case the version should be the
current development effort ("2.4.0"), or it refers to an
external script, and should be "extension".
If the bug looks like a duplicate, try to find the other bug
and link the two. It is not necessary to reject the bug.
Sometimes duplicate bug reports contain complementary
information, which is useful.
If the bug can be replicated, please do so, and add your
finding to the issue. More evidence is better, and often
helps to narrow down the cause.
If there is a clear workaround to the bug, add the information
to the issue, so the submitter can continue to work. Helping
the submitter work around the problem is important, because
the eventual fix will take time, perhaps months. Always try
to educate the user and don't forget that these issues are
permanent and therefore searchable and useful to everyone.
If a bug looks like a really big problem, tell people, make a
Same as "Bugs" above , but with these differences:
"Target version" should always be "BACKLOG". This is a
non-specific future release. Features should be cherry-picked
out of the "BACKLOG" version and moved to the current
development version. They should not default to the current
development version, where we have to defer them constantly.
It gives the wrong impression to have a giant list of
features under the current development effort - it makes
people think the next release is going to be huge, which is
rarely the case.