Skip to content

Latest commit

 

History

History
102 lines (80 loc) · 4.61 KB

CONTRIBUTING.md

File metadata and controls

102 lines (80 loc) · 4.61 KB

Contributing

When contributing to this repository, please first discuss the change you wish to make via issue with the maintainers of this repository before making a change.

Please note we have a code of conduct, please follow it in all your interactions with the project.

Opening an Issue

New Feature/Feature Request

A new feature should have the enhancement label, with a title describing the new feature (“Add new screen for maps”).

If the feature is an UI improvement or a new screen, please provide a wireframe of the screen.

The issue message should explain what the feature is going to change in the app and possible conflicts (“The new endpoints will change the list item in the Home Screen”).

Commits

  • Write clear meaningful git commit messages (Do read http://chris.beams.io/posts/git-commit/)
  • Make sure your PR's description contains GitHub's special keyword references that automatically close the related issue when the PR is merged. (More info at https://github.com/blog/1506-closing-issues-via-pull-requests )
  • When you make very very minor changes to a PR of yours (like for example fixing a failing travis build or some small style corrections or minor changes requested by reviewers) make sure you squash your commits afterwards so that you don't have an absurd number of commits for a very small fix. (Learn how to squash at https://davidwalsh.name/squash-commits-git )
  • When you're submitting a PR for a UI-related issue, please try to add a screenshot of your change or a link to a deployment where it can be tested out along with your PR. This makes reviewing quick and easy for the reviewers.

Additionally, each commit message must follow this set of rules:

  • Reference the issue that you are fixing/adding as a feature
  • Explain what the commit does (“Fixes issue #1), “Adds a button to the bottom bar for ‘Home’”)
  • Use the present tense (“Add feature” not “Added feature”)
  • Use the imperative mood (“Move cursor to…” not “Moves cursor to…”)

Pull Request Process

  1. Ensure any install or build dependencies are removed before the end of the layer when doing a build. Add only relevant files to commit and ignore the rest to keep the repo clean.
  2. Update the README.md with details of changes to the interface, this includes new environment variables, exposed ports, useful file locations and container parameters.
  3. You should request review from the maintainers once you submit the Pull Request.

Instructions

  • Git Workflow
## Step 1: Fork Repository

## Step 2: Git Set Up & Download
# Clone the repo
$ git clone git@github.com:<User-Name>/<Repo-Name>.git
# Add upstream remote
$ git remote add upstream git@github.com:DesignrKnight/quantum.git
# Fetch and merge with upstream/main
$ git fetch upstream
$ git merge upstream/main

## Step 2: Create and Publish Working Branch
$ git checkout -b <type>/<issue|issue-number>/{<additional-fixes>}
$ git push origin <type>/<issue|issue-number>/{<additional-fixes>}

## Types:
# wip - Work in Progress; long term work; mainstream changes;
# feat - New Feature; future planned; non-mainstream changes;
# bug - Bug Fixes
# exp - Experimental; random experiemntal features;
  • On Task Completion:
## Committing and pushing your work
# Ensure branch
$ git branch
# Fetch and merge with upstream/master
$ git fetch upstream
$ git merge upstream/main
# Add untracked files
$ git add .
# Commit all changes with appropriate commit message and description
$ git commit -m "your-commit-message" -m "your-commit-description"
# Fetch and merge with upstream/main again
$ git fetch upstream
$ git merge upstream/main
# Push changes to your forked repository
$ git push origin <type>/<issue|issue-number>/{<additional-fixes>}

## Creating the PR using GitHub Website
# Create Pull Request from <type>/<issue|issue-number>/{<additional-fixes>} branch in your forked repository to the master branch in the upstream repository
# After creating PR, add a Reviewer (Any Admin) and yourself as the assignee
# Link Pull Request to appropriate Issue, or Project+Milestone (if no issue created)
# IMPORTANT: Do Not Merge the PR unless specifically asked to by an admin.
  • After PR Merge
# Delete branch from forked repo
$ git branch -d <type>/<issue|issue-number>/{<additional-fixes>}
$ git push --delete origin <type>/<issue|issue-number>/{<additional-fixes>}
# Fetch and merge with upstream/main
$ git checkout main
$ git pull upstream
$ git push origin