Skip to content

Contributing

Ted Hwang edited this page Jan 3, 2021 · 54 revisions

General

Mipa is built on Quasar framework and Firebase. Getting to know them will be helpful to contributing to this project. Quasar is based on Vue, so if you're familiar with Vue then you'll feel at home here.

D3.js also has an important role; we'll much appreciate help in this area, too.

Contribution workflow

  1. Discuss what you want to work on with the maintainers.
  2. Fork and clone the mipa repository if you haven't already done so, then set the remote upstream repository that will be synced with your fork. From your cloned repository, run:
git remote add upstream https://github.com/collective-change/mipa.git
  1. Merge latest changes from upstream/master (the collective-change/mipa repo) to your local master:
git checkout master
git fetch upstream
git merge upstream/master
  1. Create and checkout a feature branch.
git checkout -b your-feature-branch
  1. If you haven't done so, go through instructions at Setting up your instance and Setting up development environment to get ready to develop.
  2. Make your changes to tests and/or code.
  3. When you're happy with your changes, you can run tests like they would be run on the continuous integration server. First stop the Firebase emulators, then:

On *nix systems:

firebase emulators:exec --import=initial-firestore-emulator-data "./scripts/unit-tests.sh"

On Windows:

firebase emulators:exec --import=initial-firestore-emulator-data ".\scripts\unit-tests.sh"
  1. Merge the latest upstream/master into your feature branch, then push to your fork. If changes are introduced to your code during this process, pleaes do the above step again to check for and fix possible errors.
git fetch upstream
git merge upstream/master
git push -u origin your-feature-branch
  1. Create a pull request. See creating a pull request from a fork.
  2. If you need to do rework on the feature branch after submitting a pull request, do not rebase your additional commits. Simply push them to the feature branch on your fork. The pull request will update automatically.
  3. When the pull request has been accepted or otherwise closed, you may delete your feature branch and pat yourself on the back for the contribution.

Note: Be careful not to merge your feature branch into your master branch. Only merge your master branch with upstream/master, so it stays looking the same as upstream/master. In case you've messed up your master branch, do this to get it even with upstream/master:

git checkout master
git pull upstream master
git reset --hard upstream/master
git push origin master --force

Contributor License Agreement?

Well, we don't use one. We rely on the "Contributions Under Repository License" section of GitHub's Terms of Service, also known as the "inbound=outbound" policy.