Contributing

Contributing

So you've found a bug you want to fix, or a feature you want to implement, thanks!

If you follow this guide it will make it much easier for the community to review your changes, and the core team to get them included in the next release. If you need an introduction to Mercurial, check out the tutorial and BitBucket Guide.

Making Your Changes

The first thing you need to do is obtain a clone of the repository

$ hg clone http://bitbucket.org/Bounga/i18nfloat
$ cd googlus

Now you're ready to get hacking.

Be sure to include tests which demonstrate the bug you're fixing, and fully exercise any new features you're adding. You should also take care to make sure the documentation is updated if you're changing the API. Once you've finished making your changes you need to commit them.

$ hg commit -m "I solved annoying bug #1234"

Preparing your changes for submission

Now that you've made your changes it's time to get them into a patch. We need to update and fix any conflicts we had.

$ hg pull
pulling from http://bitbucket.org/Bounga/i18nfloat/
searching for changes
no changes found

Once you've fixed any conflicts, you're ready to create a patch:

$ hg export tip > your-well-named-patch-file.diff

Now you can attach that patch file to a BitBucket ticket and set its type to bug or enhancement whether its correcting a bug or adding a new feature.

Reviewing Changes

To apply someone's changes you need to first clone the repository:

$ hg clone http://bitbucket.org/Bounga/i18nfloat
$ cd i18nfloat

Then you can apply their patch

$ hg import their-patch-file.diff

Once you have a working copy, you should take note of the following kinds of things:

  • Are you happy with the tests, can you follow what they're testing, is there anything missing
  • Does the documentation still seem right to you
  • Do you like the implementation, can you think of a nicer or faster way to implement a part of their change

Once you're happy it's a good change, comment on the BitBucket ticket indicating your approval. Your comment should indicate that you like the change and what you like about it. Something like:

+1. I like the way you've restructured that code in foo method, much nicer. The tests look good too.

If your comment simply says +1, then odds are other reviewers aren't going to take it too seriously. Show that you took the time to review the patch. Once three people have approved it, this will bring it to the attention of a committer who'll then review the changes looking for the same kinds of things.

If there's no reviewer to approve your patch, the ticket will be treat as soon as possible.

Notes

Use a BitBucket fork only for large changesets which are likely to involve a lot of code reviews/changes back and forth, or if 2 or more people are working on the same feature/bug. In most case a patch file is enough.

Updated

Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.