Contributing to the codebase - lokothodida/gs-custom-menu GitHub Wiki

GS Custom Menu is free to use and OpenSource. If you wish to add to the code, be it fixing a bug or adding a feature, you are free to. Please ensure that you follow the below guidelines.

Submission

  1. Fork the repository over to your own account.

  2. Checkout master, ensure that it is up to date*, then checkout a new branch with a brief but suitable name for the changes you are making (e.g. add-feature-x)

  3. Make the changes on that branch, ideally with a healthy number of commits to show the progress made.

  4. Make a pull request, describing the changed made with the following structure (you may copy-paste it and edit where appropriate):

    ## Who worked on this update
[insert collaborators]

## Describe main features added/changed
1. [insert feature]
2. [insert feature]

## What version of GS Custom Menu was edited
[insert version]

## What changes to the documentation or API will be needed
[insert changes]

  5. If the changes are suitable, they will be merged into the master branch and included as a new release.

( * ) to ensure master is up to date on your fork, do not use git pull. Please do the following:

$ git checkout master
$ git status               // see if there are any unstaged changes
$ git fetch
$ git reset origin/master
$ git reset --hard         // overwrites local master branch with files from remote branch

Code guidelines

  • Spaces for indentation as opposed to tabs.
  • Adding to the existing API (within reason) is acceptable. Changing the existing API is undesirable, unless there is an imperative to do so (i.e. a major security fix that cannot otherwise be implemented without those changes). On the whole, the general use of GS Custom Menu (from the end-user's perspective) should not change, even if 'under-the-hood' the codebase is completely revamped between releases.
  • Provide documentation in the code for any new methods or variables introduced
  • Comment on any and all logic which may not be explicitly clear. Where possible, verbose variable/method names are welcome.
  • Avoid non-descriptive names for variables/methods unless they are for short control structures (e.g. i for for or while loops).
  • Adding to the examples and showing more advanced and extensive/creative use is wholly appreciated.
  • When in doubt, look at the existing codebase for guidance.