Skip to content

Latest commit

 

History

History
120 lines (68 loc) · 3.72 KB

CONTRIBUTING.md

File metadata and controls

120 lines (68 loc) · 3.72 KB
Raw

Contribution Guidelines

This document contains a set of guidelines which any contributions to wagyufari/dzikirqu-android repository must follow.

If you disagree with something here, you should open up an issue to discuss making a change!

Table of Contents

  1. GitHub Flow
  2. Branch Names
  3. File Names
  4. Git Commits
  5. Making a Pull Request

GitHub Flow

We use a modified version of GitHub Flow at wagyufari/dzikirqu-android. The only difference is instead of deploying from a reviewed pull request, we merge first and deploy straight from master.

Part of the GitHub Flow is submitting pull requests. See https://help.github.com/articles/using-pull-requests/ for a good overview of what pull requests are and how to use them. We use the fork & pull model for managing contributions.

Branch Names

Branch names should adhere to the following:

  • All lowercase
  • - as space separator for branch names
  • If a feature branch, include the name of the feature

File Names

File names should follow the following guidelines:

  • All lowercase
  • _ as space separator for file names
  • - as a space separator for dates in file names
  • Dates in DD-MM-YYYY format

Git Commits

In order to ensure that our git history makes sense we have certain guidelines which we require contributors to adhere to. These are:

Commits should follow the commit standards

These are:

  • Commits should be written in the imperative mood
  • Commits should start with a capital letter
  • Commits should not end with a full stop

This is a style used by many other Open Source projects (Linux, Rails) as well as most corporate software development shops.

This is a great guide on writing a git commit message

Examples

fix typo in introduction.

  • Does not start with a capital letter
  • Ends with a full stop

Added Upin & Ipin GIF

  • Does not use the imperative mood

Adding more bakso restaurants to directory

  • Does not use the imperative mood

Fix typo in introduction to user guide

This commit message is wonderful!

Commits should be one logically unit of change

A logical unit of change can be thought of as completion of a single task.

A good way to figure out if you are not adhering to this rule is to tell yourself what you changed ("I added a picture of a cow to the Bottom navigation bar"). If you find yourself having multiple statements in this description then you have made your commit too big.

Examples

Add an image of bakso, fix typos, rewrite README.md

This commit message contains three units of change, they are:

  • An image of bakso
  • Fixed typos
  • Rewrote README.md

These should be split into one commit each.

Add an image of bakso

This commit is great as only one logical change was made.

Commits should explain the change, but not be longer than 50 chars

A commit message is used for quickly summarizing a change. Another contributor should be able to read it, along with the content and immediately understand the change does.

Examples

Fix typo

  • This commit message does not give any context

Add the nuclear reactor source code into the document where we add our thoughts

  • This commit message is too long! It should be less than 50 characters!
  • It uses too many words and could be simplified

Making a Pull Request

Here are some steps on how to make and commit a change, and create a pull request for review, using GitHub's web interface.

  1. Navigate to the file to edit

  2. Make your changes

  3. Commit your changes and add a message

  4. Make a pull request