Skip to content

Instantly share code, notes, and snippets.

@jarnheimer
Last active July 9, 2019 07:30
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jarnheimer/3e4a844b808024b2d8b8fd43202efae5 to your computer and use it in GitHub Desktop.
Save jarnheimer/3e4a844b808024b2d8b8fd43202efae5 to your computer and use it in GitHub Desktop.
Example of CONTRIBUTING guides

Contributing to Project A

👍🎉 First off, thanks for contributing! This is an example of a contribution guide for a small project. 🎉👍

Getting started

  • Submit a GitHub Issue for your issue if one does not already exist.
    • Clearly describe the issue including steps to reproduce when it is a bug.
    • A ticket is not necessary for trivial changes.

Making changes

Git

Branches

We are using the main ideas of GitFlow. Which means:

  • Two permanent branches:
    • master
    • develop
  • Supporting branches
    • feature branches (named feature/name-of-feature)
    • hotfix branches (named hotfix/name-of-hotfix)

However, we are not using release branches and we are forking the central repo.

Pull requests

Use pull request from feature branches to develop. Add one code reviewer. If you are new to the team, always include your supervisor as a code reviewer.

Commit messages

Good commit messages serve at least three important purposes:

  • To speed up the reviewing process.
  • To help us write a good release note.
  • To help the future maintainers (it could be you!)

The summary should be:

  • Keep it short and informative
  • Don't end the summary line with a period
  • Write in imperative mode. For example Fix instead of Fixed
  • Mention the issue id in the code. For example #92 Add new field to contact details
  • More ideas about good messages

Standards

  • Follow PSR standards
  • In addition to PSR-2, follow the PSR-2 R guides by php-fig-rectified.
  • Follow Laravel built in features. If the Laravel-way is not followed, it should a result of a thoroughly decision and be will documented in the README file
  • Follow the best practice for Language files
  • When storing something in the cache, we use our one practices. Always start the name with db, report or other. For example
cache('db.users', $users);

Other

  • Keep the README.md up-to-date
  • Keep example.env up-to-date

Note on technical debt

A) Activily look for things that should be refactored.
B) Rewrite the methods needed only if they are touched. (Current take on technical debt)
c) We value short-term performance highly and are therefore not focusing on any technical debt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment