Bug Triage

Bugs in OpenJFX are cleared by the teams daily.  It is unlikely that a bug will remain untriaged for a long period of time but this can happen in circumstances where it is unclear where the bug should go.  Here is a link the something that is sometimes called "inbox" (the untriaged bugs).  For example here is Inbox for 8u40: 

https://javafx-jira.kenai.com/secure/Dashboard.jspa?selectPageId=12304

Triaging bugs in OpenJFX

Triaging is the process of evaluating a bug and determining when and who should work on it.  Sometimes it is hard to determine which component is at fault or who a bug should belong to.  Fortunately, OpenJFX has the concept of code ownership and clear responsibilities in the code base.

1. Ensure that the bug has test code and steps
   If a bug does not have enough information to recreate it, then the bug will be closed as incomplete.  There are some exceptions to this rule, for example, the submitter might already know that the bug cannot be recreated easily.  In general, we require sample code and numbered steps before we can fix a bug.
2. Ensure that the bug has a meaningful title
   Very often, we process huge lists of bugs.  It is very helpful if the title of the bug describes is as accurately as possible without being too long to read.  Bug titles like "XXX doesn't work" require us to click on the bug every time or remember exactly what doesn't work every time we process bug lists.
3. Ensure that the following are set correctly:
   1. IssueType - <MORE HERE>
   2. Component - <MORE HERE>
   3. Priority - <MORE HERE>
   4. FixVersion - <MORE HERE>
   5. Assignee - <MORE HERE>
   6. Key Words - <MORE HERE>
4. Perform an initial assessment
   When a bug submitter provides steps and code, the bug needs to be recreated.  If the problem does not happen, the bug may have already been fixed or the submitter may be mistaken about the issue.  If the problem does happen, then it might be a regression.  This is quite easy to prove by running the code under older release, starting with the last update release (XuYY) and moving backward.
5. Select 'Evaluation Complete'
   This should only be done a project lead or technical lead.  It is important for project leaders to keep track which bugs are being fixed right away and which are being deferred or moved to another release.  This is especially critical during ramp down phases and milestones.

 

****** OLD CONTENT ***** IN PROGRESS *******

1. Ensure that the following are set correctly:  

   IssueType 

   Component 

   Priority (default = P4, but you may need to adjust) 

   FixVersion (default is EMPTY, which is not OK for bugs)

      This must be (for example) "Lombard" for P1-P3 bugs.

      During rampdown, this should be "9" for P4-P5 bugs and for all Features and Tweaks.

   Assignee (someone who will look at the bug) 

2. Select "Evaluation Complete" to indicate that the above are correct.