We encourage members of the community to help us fix bugs in the Trac bug tracking system ( http://bugs.jqueryui.com/ ). To start, you will need to fork the jQuery UI 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://bugs.jqueryui.com/. 

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")
• If tests exist for the component you have been working on, make sure they still pass.
• Make sure your code conforms to the jQuery UI coding standards.
• Submit a pull request after your commit and add a link to your commit in a comment on the ticket.

How to properly close an issue:

• 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), followed by a period (.)
3. The WHY #Num - the ticket number with a #sign so Trac creates a hyperlink (example: #1234), followed by a hyphen/dash (-)
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 ----------------/