A useful report often starts as “is anyone else seeing this?” The job of triage is to turn that conversation into work someone can act on, without losing the details that explain the problem.
You can use this process with your existing tracker. The taskl.ie notes explain how the same steps map to our Discord integration.
1. Keep the source, then collect the essentials
Save a link to the original message or thread. Record what happened, what the person expected, and the smallest set of steps that reproduces the problem. Include the app version, browser or device when they matter. Screenshots can help, but should not replace a written description.
Do not copy unrelated chat into the issue. Remove tokens, private account details and other sensitive material before sharing it with a wider audience.
2. Decide whether this is new work
Search the tracker for the symptom and affected area. A report may add evidence to an existing bug rather than justify another issue. Link the new source to the existing work where possible. If the behaviour is unclear, ask one specific question that will change the next decision.
3. Review the proposed issue
In taskl.ie, run /task, mention the bot, or use the message action to create a task from a report. The bot gathers bounded context and proposes work. Ordinary messages do not invoke it. Check the source context and edit the proposed title, description, project and assignee before confirming.
A draft is not proof that the diagnosis is correct. Keep observations separate from suspected causes. “Safari returns to the login page” is an observation; “the cookie is misconfigured” is a hypothesis until someone checks it.
Example issue brief
Safari sign-in returns to the login page
- Observed
- After signing in on Safari 18, the login page appears again.
- Expected
- The signed-in workspace opens.
- Scope
- Reproduced on Safari; Chrome appears unaffected.
- Source
- Link to the original report and reproduction discussion.
- Next step
- Assign an owner to reproduce and investigate session handling.
4. Give it an owner and a next action
An issue needs someone responsible for the next step, even if that step is investigation. Set the team and project, choose an appropriate status, and use priority to express urgency rather than how loudly a report was made. A useful triage queue separates reports needing clarification from work ready to start.
5. Keep implementation connected
Link the pull request or commit to the issue. Put investigation notes and important decisions on the issue so another developer—or an authorised AI tool—can find them. In taskl.ie, MCP tools can read project context and update work within their granted access.
6. Verify delivery, then report the outcome
Check the environment where the fix is available. With deployment reporting connected, taskl.ie can associate delivered changes with issues and show milestone progress. Test the original reproduction steps against the deployed version before telling the reporter the problem is solved.
Reply with a clear outcome and a link to the tracked issue. Discord activity notifications can keep configured channels informed, but do not assume every person who reported a bug has received a direct message. Decide explicitly who communicates the result.
A short weekly check
- Which reports have no owner or next action?
- Which issues still need reproduction details?
- Which merged fixes have not reached production?
- Which reporters are waiting for a clear answer?
Start with these questions before adding more automation. For tool selection, compare taskl.ie and Linear or taskl.ie and GitHub Issues.