Typical Contribution Process

• Talk to the team first

Making sure that the sub-project (also known as "module") maintainer knows a change is coming is often useful in order to avoid duplication of effort, wasting time on unwanted features, or as a heads up to find time for reviews.

• Search for existing bug reports
• File a new bug report if necessary
• Describe the problem or enhancement precisely
• Engage a designer if possible
• Check out the source code
• Read and understand the terms of the license
• Make micro commits to your working tree
• Squash and rebase your changes

Make one change per git commit. Make as many separate git commits as you need to fix the bug. But before you submit the changes for review ensure the changes are a logical sequence of atomic changes. Each commit should make sense on its own if possible. Each should have a proper author, subject, and description.

• Test your changes
• Use "git-bz" to submit to Bugzilla
• Patiently wait for patch and design review
• Update your patch based on the review
• Return to "Test your changes" above as necessary
• Once satisfied, the maintainer will mark the patches as "approved".
• Use git-bz to push the changes and close the bug
• Celebrate! You've made a difference.