Page History

...

Bugs in OpenJFX are cleared by the teams daily.  It It is unlikely that a bug will remain untriaged for a longer long period of time but this can happen in circumstances where it is unclear where the bug should go.  Here Here is a link to the something that is sometimes called "inbox" (the untriaged bugs):  <PROVIDE LINK>

To triage bugs in OpenJFX

untriaged bugs (bugs that are in the "New" state):

https://bugs.openjdk.java.net/issues/?filter=23827

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 reporter 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 - Bug versus Enhancement
   2. Component/Subcomponent - <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 reporter 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 reporter 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. If more information is needed, then "resolve" the bug as "Incomplete" and request more information from the bug reporter.
5. Press the 'Triage' button

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

1. Ensure that the following are set correctly:  

   IssueType 

   Component (should be javafx)

   Component Subcomponent

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

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

      This must be (for example) "Lombard9" for P1-P3 bugs; during rampdown, this should be "9" for bugs.

      This can be either "9" or "tbd_major" for P4-P5 bugs.

      This can either be "tbd_major" (a good default) or "9" for Enhancements.

      During rampdown for a release, P4-P5 bugs and for all Features and Tweaksall Enhancements should go to "tbd_major" or the next release.

   Assignee (someone who will look at the bug) 

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