Contribution Guidelines

How do I start contributing?

• Onboarding
  1. Introduce yourself to the community on Slack!
  2. Pick up an easy issue that you think you can work on. Familiarize yourself with the context. Read up on the existing codebase that is relevant to the issue.
• While writing the code
  1. Follow proper styling guidelines for your code. Ensure that your code is style consistent. A useful guide may be found here
  2. If you wish to use a static code analyzer, you may use (add link to code analyzers in language of project such as rubocop, jslint, coala)
  3. Use comments wherever necessary. Comments explain the how and why of code (not what does the code do, variable names and functions should be self-explanatory in that terms) and are useful for maintainers. Make sure your comments are not too numerous or verbose.
  4. Do not add author comments.
  5. Use strings.xml for the hard coded strings.
  6. Use dimensions.xml for all the hard coded dimensions.

Issue Reporting Best Practices

1. Go through the Issue List and see whether the issue you found or any related issue is already reported.
2. If you don't find the issue you are reporting in issue list, check whether it is reported and closed (present in closed issue list).
3. If the issue is new, report the issue as a new one with following:
   • Screen shot (or GIF) if possible
   • Short description for the title
   • A detailed description with steps to recreate the issue

Best Practices to create a Pull Request

1. When sending a PR have an appropriate title referencing the issue which it solves. Add “fixes #” in the title, so that when the PR gets merged, the issue gets closed automatically. Do not do this if the PR solves only a part of the issue.
2. Add a screenshot (or a GIF) if the change can be reflected.
3. Have a short description on what has gone wrong (like a root cause analysis and description of the fix), if that information is not already present in the issue.

Writing effective commit messages

1. Use meaningful commit messages.
2. Try restricting your commit message to 50 characters.
3. Use imperative - ‘change cache behavior’ instead of ‘caching behavior changed’.
4. Paragraph summary explaining the change on a high level using 72 chars to 80 chars if your change is big, the paragraph can contain bullets.
5. Do not over commit. (Do not include multiple commits for a small change. Squash commits into one for small changes before merging the PR.)
6. Do not add the merge commits to the PR.
7. Usually use a single commit for a single issue, unless the issues are related or contain a significant code change.
8. There are certain kind of files you do not add to source control. If you already don't know about them, please do a quick search and find them and remove them from your commit.
9. Do not commit whitespace changes. A lot of text editors add auto formatting to code. A useful guide may be found here.

Here's a guide to writing good commit messages.