• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!


How To Triage jQuery UI Tickets

Page history last edited by TJ VanToll 11 years, 5 months ago Saved with comment

Check that critical FIELDS are complete and accurate

  • properly formatted summary
    • PLUGINNAME: Issue XX in browser YY when attempting ZZ
    • PLUGINNAME: Option XX cannot be changed after init
    • PLUGINNAME: Error when double clicking in browser YY
  • type [ bug, feature ]
  • version [ version of jQuery UI bug was spotted in ]
  • component [ which plugin the bug is in ]



If a ticket already exists for the same bug/feature, close the ticket as duplicate. In most cases, tickets should be closed as duplicates of the ticket with the lowest number. Two possible excetions:

  • A later (higher number) ticket could be the master if it is sufficiently more complete or clear and the earlier ticket does not already have duplicates
  • A later (higher number) ticket could be the master if it already has duplicates



  • ensure minimal test case is linked, create one if needed.
    • send back to reporter if not dead simple and obvious how to create based on summary and description.  This can be done by choosing the "needs info; return to reporter" action.  The reporter will have 14 days to respond or the ticket will be automatically closed.
    • the reporter can be pointed at http://jsfiddle.net/tj_vantoll/Qp39S/show/ for a list of minimal test cases to use as a starting point. 
  • if reproduced with minimal test using ticket version, test with latest version


Clean up secondary FIELDS

  • description
    • ensure that the description is accurate and complete
    • If type is ‘bug’:
      • what is being attempted generally (why)
      • what steps are being taken (how)
      • what is the expected outcome
      • what is the actual outcome
    • If type is ‘feature’:
      • what is being attempted generally (why)
      • what could be possible if feature XX were added, and how it would work (how)
  • priority
    • blocker = cannot do the next release with this ticket open
      • bugs = block minor releases
      • features = block the set milestone
    • high = standard priority, team will work on these tickets
    • low = team will not work on these tickets unless there are no other tickets; help from the community is welcome



  • If type is ‘bug’:
    • If can reproduce and is reasonably expected to work, mark as 'valid'
    • If can reproduce and not reasonable expected to work, close as ‘invalid’
    • If can reproduce and the team determines it can’t possibly or reasonably be fixed, close as ‘wontfix’. Wontfix should not be used to communicate low priority issues that should stay open welcoming patches.
    • If cannot reproduce with linked minimal test case using ticket version, close as ‘worksforme’
  • If type is ‘feature’:
    • If team agrees feature is reasonable to implement, mark as valid. If unsure, ask the team on the ui-dev forum.
    • If team does not agree to implement feature, close as ‘wontfix’. If unsure, ask the team on the ui-dev forum.



  • If someone has taken the time to file a ticket, please be courteous when responding. If the ticket is invalid, explain why. If the bug tracker is not the correct forum, kindly point them in the right direction. If it’s an existing plugin, that’s the using-jquery-ui forum. If it’s a new plugin under development (not yet in Trac) that’s the wiki.


Comments (0)

You don't have permission to comment on this page.