Add Trac Keyword Triage Guide for Test Team Members

[juanmaguitar]

Problem

Testers don't have clear guidance on which Trac keywords to use and when. This leads to inconsistent triaging and confusion about when to test vs. escalate.

Proposed Solution

Add a "Trac Keyword Triage Guide" to the handbook with:

1. Definitions of the four main testing keywords testers manage
2. A workflow diagram showing when to use each keyword
3. Practical examples of common scenarios

Content

The Four Keywords

Keyword	When to Use	Action
needs-testing	After code review is complete and patch is ready for testers	Add this keyword to signal testers can start testing
needs-test-info	Testing instructions are unclear or missing	Add when testers need more information about how to test
dev-feedback	Technical details needed to understand the issue for proper testing	Add when testers need technical clarification from developers
needs-refresh	Patch has merge conflicts and won't apply cleanly	Remove needs-testing, then add needs-refresh Note: This is Trac-specific. Unlike GitHub, Trac requires manual flagging of merge conflicts

Workflow Diagram

When you see needs-testing, follow this decision tree:

1. Has this been reviewed by someone with commit access?

   • NO → Remove needs-testing, add dev-feedback
   • YES → Continue

2. Do I have enough information to test?

   • NO, missing test steps → Remove needs-testing, add needs-test-info
   • NO, need technical details → Remove needs-testing, add dev-feedback
   • YES → Continue

3. Does the patch apply cleanly?

   • NO → Remove needs-testing, add needs-refresh
   • YES → Test it

Why This Helps

• Testers will use keywords consistently
• Less back-and-forth on tickets
• Easier to onboard new testers
• Clear rules for when to escalate vs. test

Notes

This focuses on the tester's view of triage. These four keywords are what testers manage day-to-day - there are other keywords, but they're handled by other roles.

[ozgursar]

Thank you. This diagram would greatly help new testers understand the key tags and how to proceed with accordingly.
I have a couple of ideas to revise / further develop this idea:

• New Ticket label may me misleading to some people that tickets should not start with a tag needs-testing. So, maybe we can relabel it as "A Ticket gets tagged with needs-testing"
• Also, it might be helpful if we can provide testers with some kind of "placeholder text" that they can change slightly when adding comments to tickets along with adding/removing tags, similar to the test reports plugin we are using that gives us the placeholder. (For example, what to write into the comment field when a patch doesn't cleanly apply)
• Also, I'm not sure if we need to implement bug reproduction to somewhere in this diagram.

[juanmaguitar]

Thanks @ozgursar for your feedback!

So, maybe we can relabel it as "A Ticket gets tagged with needs-testing"

Much better. Agree! 👍

Also, it might be helpful if we can provide testers with some kind of "placeholder text"

Do you have any specific suggestions?

I'm not sure if we need to implement bug reproduction to somewhere in this diagram.

I think this should be out of the scope of this guide as is meant to be focused on the "triage" aspect of a tester and the keywords involved in this process.

[SirLouen]

I think this should be out of the scope of this guide as is meant to be focused on the "triage" aspect of a tester and the keywords involved in this process.

The thing here is that this is only assuming that we are triaging just for "Needs Patch Testing"

So basically it feels we have a missing step here somewhere in between (not sure where it will be the best place)

Does it have a patch? 
-> No -> Reproduce the issue
-> Yes -> Does the patch apply cleanly? -> ...

[ozgursar]

So basically it feels we have a missing step here somewhere in between (not sure where it will be the best place)

Does it have a patch? 
-> No -> Reproduce the issue
-> Yes -> Does the patch apply cleanly? -> ...

I think we may consider inserting this at the top, before the "has this been triaged by someone" step.
Even if the ticket doesn't have a patch, a test member might want work on it, write Bug Reproduction Report and confirm that the bug occurs.

Do you have any specific suggestions?

I think if we can provide this kind of placeholder text for new testers, they can have a better understanding of the workflow diagram and have some kind of a text to modify according to the ticket.

• When a patch fails to apply:

  • I've tried applying the patch (URL_OF_THE_PATCH) against the latest trunk (LATEST_TRUNK_VERSION_DISPLAYED_IN_ENVIRONMENT), it fails to apply with the following message: (FAILED_HUNKS_MESSAGE_FROM_TERMINAL). As the patch can not be applied, I'm removing needs-testing.

• When a ticket does not have enough test info to reproduce the bug or enhancement proposal:

  • I've tried reproducing the issue mentioned in the ticket but it's not clear how to reproduce this bug / enhancement. Please describe the steps, and/or provide sample code snippet / plugin to facilitate the tests.

[3kori]

I think we may consider inserting this at the top, before the "has this been triaged by someone" step.
Even if the ticket doesn't have a patch, a test member might want work on it, write Bug Reproduction Report and confirm that the bug occurs.

This is a great place to insert the Bug reproduction step.
I have a concern about who should be allowed to tag defects/enhancements as needs-testing: the reporter, a test team member, or a core committer?