Why this is hard
A message like “done” means nothing on its own. It only makes sense next to the message it answers. In our group, 43% of all messages are replies, and many of them are one or two words.
So TXM never reads a message alone. For each message it looks at:
- the message it replies to, and the part it quotes, if any;
- the conversation above that;
- the task that conversation belongs to;
- who is speaking.
Below are the situations we see most often. The examples are simplified and the names are removed.
1. A reply that says “done”
Lead: can you fix the date format on the export?
Developer, replying: done
TXM closes the task “Fix the date format on the export”. The reply is saved with the task as the reason.
2. A build number
Lead: the login page still shows the old logo
Developer, replying: check v1.0.452
In our team, a build number in a reply means the change has shipped. TXM marks the task done and notes the build.
3. The answer is to a later question
Monday, Lead: please add the new fields to the client form
Wednesday, Lead: is this deployed?
Developer, replying to Wednesday’s question: yes
The “yes” answers the question, not the request. TXM follows the replies upward: the question is about the form, so the form task is done.
4. A screenshot as proof
Developer, replying with a screenshot of the working screen
TXM looks at the picture. If it shows the requested change working, the task is done. If it shows the same error again, the task stays open.
5. “ok” is not done
Lead: please send the invoice to the client today
Developer: ok
“ok”, “noted”, “on it” and 👍 mean someone saw the request. TXM makes that person the owner. The task stays open.
6. Not yet, or broken again
Developer: not yet, waiting for the API key from the client
Lead, a week later: the export broke again
“Not yet” keeps the task open. “Waiting for” marks it blocked and says what it waits for. “Broke again” reopens a task that was closed. A later “still broken” always wins over an earlier “done”.
7. Two tasks that depend on each other
Developer: the upload fails because the storage bill is not paid
TXM links the two tasks: the upload task is blocked by the payment task. When the payment task is done, TXM looks at the upload task again first, so it does not get forgotten.
The rules TXM follows
- Every change has evidence. Each status change points to the messages it is based on. To close a task, at least one of them must come after the request.
- People win. If someone changes a task on the board, TXM does not change it back because of older messages.
- When unsure, it writes a note. If TXM cannot tell which task a “done” belongs to, it adds a note to the likely task instead of closing it.
- Quiet is not done. TXM never closes a task just because nobody talked about it for a while. It re-checks open tasks every few days against the whole chat instead.
How well it works for us
Over nine weeks, TXM closed about 200 tasks in our group from what people wrote. People closed 28 by hand on the board. When TXM gets one wrong, anyone in the group can reopen it on the board, and TXM keeps that decision.
How to help it in your group
- Reply to the message you are answering. This one habit helps the most.
- Say “done” in the same thread as the request, or reply to the latest question about it.
- Mention the build, or post the screenshot, when that is the proof.
Read how we use TXM day to day: How we use TXM to manage our chaotic work group.