apps-android-commons/CONTRIBUTING.md
Kaartic Sivaraam 1ae28e37c3 CONTRIBUTING: fix formatting of the gist of the guidelines (#1453)
* CONTRIBUTING: fix formatting of the gist of the guidelines

First level headings for a gist seems to be overkill.

So, replace first level headings with an ordered-list which
sounds more meaningful.

* CONTRIBUTING: specify clearly that 'blame' is a feature of "Git"

The contributing file specifies about the ability to know who wrote
something without the need of @author javadoc tags but incorrectly
attributes the feature to GitHub.

Correctly attribute the feature to where it belongs, Git, and specify
the name of the feature to help users easily take advantage of it.
2018-05-18 16:52:11 +05:30

1.6 KiB

Thanks for considering to contribute to this project! A few guidelines for people who want to contribute their code to this software are documented in this project's Wiki. If you're not sure where to start head on to this wiki page.

Here's a gist of the guidelines,

  1. Make separate commits for logically separate changes

  2. Describe your changes well in the commit message

    The first line of the commit message should be a short description of what has changed. It is also good to prefix the first line with "area: " where the "area" is a filename or identifier for the general area of the code being modified. The body should provide a meaningful commit message.

  3. Write Javadocs

    We require contributors to include Javadocs for all new methods and classes submitted via PRs (after 1 May 2018). This is aimed at making it easier for new contributors to dive into our codebase, especially those who are new to Android development. A few things to note:

    • This should not replace the need for code that is easily-readable in and of itself
    • Please make sure that your Javadocs are reasonably descriptive, not just a copy of the method name
    • Please do not use @author tags - we aim for collective code ownership, and if needed, Git allows us to see who wrote something without needing to add these tags (git blame)
  4. Write tests for your code (if possible)

  5. Make sure the Wiki pages don't become stale by updating them (if needed)