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 SVN access, 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

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 current code from trunk
• If the bug is not reproducible in trunk, run the test against 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 in trunk, it should be closed as fixed. If you can track down the specific revision that the bug was fixed in, 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 have SVN commit access, attach a patch file to the ticket for review. Feel free to post a message to the jQuery UI Dev mailing list as a notification that a patch is awaiting review.

How to properly close an issue:

• When you close a ticket as fixed, include the revision number in the comment when you close the ticket. Example:
  • Fixed in r1234
  • Partial fix in r2345
• Similarly include the ticket number in the SVN commit log. 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 thread discussion the issue, the thread should be updated when the ticket is closed.

Note: by using the r1234 and #654 syntax for revisions and tickets, Trac will automatically create hyperlinks between the two. This is a tremendous help for other members of the team that will review the changesets and the tickets.

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 three components
  1. - The WHAT - a sufficient summary of the fix or change made (example: modified the foo to no longer bar)
  2. - The WHY # - the ticket number with a #sign so Trac creates a hyperlink (example: #1234)
  3. - 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:
    • "modified the foo to no longer bar (fixed #1234 - dialog: IE6 crashed when foo is set to bar)"