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

  • Whenever you search in PBworks, Dokkio Sidebar (from the makers of PBworks) will run the same search in your Drive, Dropbox, OneDrive, Gmail, and Slack. Now you can find what you're looking for wherever it lives. Try Dokkio Sidebar for free.

View
 

Bug Fixing Guide

This version was saved 12 years, 7 months ago View current version     Page history
Saved by Richard D. Worth
on May 5, 2010 at 8:42:51 am
 

We encourage members of the community to help us fix bugs in the Trac bug tracking system ( http://dev.jqueryui.com/ ). To start, you will need to fork our GitHub repository, then you can start reviewing issues that need attention.

 

To browse the current set of open tickets, go to the Trac homepage. All tickets are public to view: http://dev.jqueryui.com/. Note: you will have to be logged in to run reports or you will get an error message.

 

 

How to log a new issue:

 

In order to create new issues, you need to first register a Trac account. When creating a ticket in Trac, you must fill in the summary, description, type, component and version. The description should provide enough detail to clearly explain the problem and steps to reproduce the behavior. You may fill in additional keywords to help others find the ticket and you may add yourself to the cc list if you would like to be notified when the ticket is updated (note: the cc field doesn't currently work. See http://dev.jqueryui.com/ticket/4136 ). The core team members are responsible for triaging issues and setting the priority and milestone. The assign to field should never be set by the reporter unless they are explicitly told to do so.  By default, members do not have the rights to edit tickets so if you make a mistake when creating a ticket, you will need to enter corrections as a comment to the ticket. Tickets should have a descriptive summary and description. Keep in mind that when viewing a list of tickets the summary will be the only field that provides insight into what the ticket deals with.  If the issue was originally mentioned in a thread, the ticket should contain a link to the thread so it can be referenced later.

 

 

How to verify a bug exists:

 

  • The first step when reviewing a bug ticket is to verify that the bug does actually exist
  • To verify if the bug exists, create a simple test using the latest code from the master branch
  • If the bug is not reproducible in master, run the test against the tag matching the version listed in the ticket
  • If the bug is not reproducible in either version, the ticket should be closed as worksforme
  • If the bug is reproducible in the reported version, but not from HEAD, it should be closed as fixed. If you can track down the specific commit that fixed the bug, you should leave a comment in the ticket when closing it.  However, if you can't track it down, it is okay to just close the ticket with a note that says this has already been fixed.

 

 

How to work on an issue:

 

  • Any ticket that is not assigned or accepted is free to be worked on by any member of the community. 
  • Tickets are not auto-assigned (as they once were) based on the component because no single person is the owner or maintainer of a plugin. All team members can work on any plugin, and are encouraged to do so.  This means that going forward, the only way a ticket will get assigned to you is if you actively take it by setting the owner to your name. 
  • Please don't leave a ticket in your name unless you're actively working on it. If you are actively working on it, post regular status updates to the ticket, so progress can be seen. Otherwise it may be assumed that you're not actually doing anything on it, maybe not even aware it's in your name. 
  • If you have a ticket assigned to you and you want to remove yourself as owner, you can just choose "reassign to" at the bottom and clear out the name field.
  • If you don't know git, you can follow these instructions for how to submit a patch through the github web interface. Be sure your commit message references the ticket (see below "How to properly commit")
  • Submit a pull request after your commit and add a link to your commit in the ticket.

 

 

How to properly close an issue:

 

  • When you close a ticket as fixed, include the commit id in the comment when you close the ticket. Example:
  • Similarly include the ticket number in the commit message. Examples:
    • PluginName: fixed #654 - Full title of ticket 654 so it doesn't have to be looked up
    • PluginName: modified margin calculations to be robust (fixes #543 - Full title of ticket 543 so it doesn't have to be looked up)
    • PluginName: partial fix for #432 - Full title of ticket 432 so it doesn't have to be looked up
  • If the ticket contains a link to a forum thread discussing the issue, the thread should be updated when the ticket is closed.

 

 

How to properly commit:

  • commits should be atomic. If three separate issues are being fixed (unless they are all fixed by one change) they need to be done as three separate commits.
  • all whitespace changes should be done on their own commit. the commit message can say simply 'whitespace' Whitespace commits should not include code changes. Code change commits should not include whitespace changes.
  • Commit messages should include four components
    1. The WHERE - a single word that categorizes and provides context for the commit and its message, followed by a colon (:). This is typically the name of the plugin being worked on, but sometimes might be something like Build: or Demos:
    2. The WHAT - a sufficient summary of the fix or change made (example: modified the foo to no longer bar)
    3. The WHY #Num - the ticket number with a #sign so Trac creates a hyperlink (example: #1234)
    4. The WHY Name - the name of the ticket. Notice this is different than summary of the fix. This is a short description of the issue (example: dialog: IE6 crashed when foo is set to bar)
    • Combined into one, here's a full example:
      • "Dialog: modified the foo to no longer bar. Fixed #1234 - dialog: IE6 crashed when foo is set to bar"
      • \WHERE/:\------------- WHAT -------------/.WHY #NUM /-\---------------- WHY NAME ----------------/

 

 

Comments (0)

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