Skip to main content
Jump to: navigation, search


< SWT‎ | Devel

Triage Process Overview

The goal of “Triage” is a quick initial response to incoming bug submissions from users.
The intent is for users to receive initial feedback on their submission and for bugs to be categorized properly.

If the bug has sufficient information, then add the "Triaged" Keyword to it and optionally leave some message for the user e.g "Thank you for bug submission, we should investigate". The bug status should remain "NEW" and remain assigned to

Subsequently, when we look for new bugs to work on, we can check bugs that have the "Triaged" keyword (See queries below).
All the triaged bugs with assignee as and status=NEW are considered active but are not currently being worked on. These bugs are available for anyone in the community to work on.
Assign "helpwanted" keyword if contributions from public is welcomed.

The purpose of Status is to tell bug readers if someone is working on a bug or not:
- Status=NEW means that nobody is working on a bug, you can start work on it.
- Status=ASSIGNED means someone is already working on the bug. (But in real life sometimes bugs are forgotten, so old 'ASSIGNED' bugs should be treated as NEW).
I.e when work has started on a bug, (either by you, or patch is being provided by community), then the status can be set to "ASSIGNED". If for some reason work stops and requires a new contributor, the status should be returned back to "NEW".

See the following diagram:


As a swt developer, consider watching in Bugzilla, to get notifications about new and triaged bugs.

Triage checklist

Use the following as a guideline on how to triage a bug:

  • Check for duplicate bugs
  • Set/update Metadata correctly
  • Link to relevant bugs
  • Briefly investigate if bug is real (i.e, reproducible on latest master)
  • Ask user to test with newer version if reported version is very old
  • Request versions of SWT/OS/Gtk/Webkit. Note, Gtk/Webkit versions can be aquired by setting version variable :
  • Request a snippet (or clear steps to reproduce) if it's not clear as to how to reproduce issue
  • Ping/CC developers involved in related issue (especially when regressions occur)
  • [Optionally] try to bisect codebase for regression reports

Setting proper Metadata

  • For severity and priority, see: WTP/Conventions_of_bug_priority_and_severity.
    • Set appropriate priority. In general, we leave severity as set by user, but we can adjust it as well. Ex for enhancements set "enhancement".
  • Prefix OS and Component to bug summary.
    • OS: [GTK][GTK2][GTK3][Wayland][Cocoa][Win32]
    • Component: [PI][Graphics][Theme][Accessibility][Printing][DnD][Clipboard][OpenGL][Browser][StyledText][Layout][Examples][Snippets][JUnit][64][I18N][AWT][HiDPI][Custom widgets][Bidi]
    • Note:
      • PI means Native library interface.
      • 64 means 32/64 bit issues.
      • I18N means Internationalization issues.
      • BiDi means Bi-directional text
    • ex: [GTK3][Theme] Button background not styled.
  • Bug reports which are regressions can make use of the "regressions" keyword
  • Set appropriate target milestone if we plan to fix it within a particular time frame, check with a committer if unsure

Triage Bugzilla Queries

New Bugs

Triaged bugs

Query Construction

To construct the queries above:

Open an incognito browser. (so that everything is hard-coded into URL)

Use quick search. For example:

  •  :swt -!Triaged
  •  :swt -!Triaged os:All,Linux,CentOS -os:Windows
  • etc.

Columns were changed, such that the following were kept:

  • Product, Component, Priority, Severity, Votes, Status, Whiteboard, Target Milestone, Summary, OS, Changed, Opened, Keywords, Tags, Reporter, Version, # of comments
  • "Stagger Headers" was used.

Then result was sorted in desired order: Priority, Votes, Severity, Target Milestone

URL was copied.


In the past, triaged bugs were re-assigned from a to a user. Instead, we now just add the "Triage" keyword.

In the distant past, bugs were assigned to component owners, but that lead to component owners to have large amount of bugs that they did not actually work on.

Some projects used to use platform-inbox, but to mark a bug as triaged, the "ASSIGNED" status was used. But this could lead to confusion where users could think that

Back to the top