Skip to content
This repository has been archived by the owner on Oct 12, 2019. It is now read-only.

Latest commit

 

History

History
121 lines (84 loc) · 6.07 KB

CONTRIBUTING.md

File metadata and controls

121 lines (84 loc) · 6.07 KB
Raw

Contributing to eCatch Kyst

The following is a set of guidelines for contributing to eCatch Kyst and its subsystems, which are hosted in the ecatch-it2901 repository on GitHub. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.

Table Of Contents

How Can I Contribute?

Styleguides

How Can I Contribute?

Reporting Bugs

This section guides you through submitting a bug report for eCatch Kyst. Following these guidelines helps maintainers understand your report 📝, reproduce the behavior 💻 💻, and find related reports 🔎.

Before creating bug reports, please check this list as you might find out that you don't need to create one. When you are creating a bug report, please include as many details as possible. Fill out the required template, the information it asks for helps us resolve issues faster.

Note: If you find a Closed issue that seems like it is the same thing that you're experiencing, open a new issue and include a link to the original issue in the body of your new one.

Before Submitting A Bug Report

  • Perform a cursory search to see if the problem has already been reported. If it has and the issue is still open, add a comment to the existing issue instead of opening a new one.

Local development

To start developing, follow these steps:

git clone git@github.com:balazsorban44/ecatch-it2901.git
cd ecatch-it2901
yarn
cd functions
yarn

Keep in mind, that yarn is not a must, we do recommend it.

Also some other tools you find useful:

You can run yarn serve to start the local server.

To run tests, you can do yarn test:watch

To build/deploy, you can do yarn build and yarn deploy though we recommend you let Travis CI do that.

Git Flow

We try to follow Git Flow. For you, this means the following:

master and develop branches are protected, meaning you must make a PR if you wish to contribute to them. The normal workflow is, that you first make an issue, following the Feature request issue template. Then you create a branch from develop, to have the most up-to-date code as a starting point. The branch name begins with feature, and follows kebab-case (feature/this-is-a-branch). Whenever you are satisfied with your work, and have checked that you wrote all the necessary tests and documentation, please update the CHANGELOG.md. Then you are ready to open a Pull Request.

Pull Requests

The process described here has several goals:

  • Maintain quality
  • Fix problems that are important to users

Please follow these steps to have your contribution considered by the maintainers:

  1. Follow all instructions in the template
  2. Follow the styleguides
  3. After you submit your pull request, verify that all status checks are passing
    What if the status checks are failing?If a status check is failing, and you believe that the failure is unrelated to your change, please leave a comment on the pull request explaining why you believe the failure is unrelated. A maintainer will intervene.

While the prerequisites above must be satisfied prior to having your pull request reviewed, the reviewer(s) may ask you to complete additional design work, tests, or other changes before your pull request can be ultimately accepted.

Styleguides

Git Commit Messages

  • prefer lowercase, unless it is an abbreviation or you have another good reason ("URL")
  • use the present tense ("add feature" not "added feature")
  • use the imperative mood ("move cursor to..." not "moves cursor to...")
  • reference issues and pull requests liberally after the first line
  • if your commit does not require CI to run, add [skip ci] to the commit title
  • consider starting the commit message with an applicable emoji:
    • 🌐 :globe_with_meridians: when working on translations / language related stuff
    • 🔧 :wrench: when updating config files
    • ✨ :sparkles: when introducing a new feature
    • 💄 :lipstick: when adding/updating UI and style files
    • 🎨 :art: when improving the format/structure of the code
    • 🚧 :construction: when you are commiting something that is work in progress
    • 🐎 :racehorse: when improving performance
    • 📝 :memo: when writing docs
    • 🐛 :bug: when fixing a bug
    • 🔥 :fire: when removing code or files
    • 💚 :green_heart: when fixing the CI build
    • ✅ :white_check_mark: when adding/updating tests
    • 📸 :camera_flash: when updating test snapshots
    • 🔒 :lock: when dealing with security
    • ⬆️ :arrow_up: when upgrading dependencies
    • ⬇️ :arrow_down: when downgrading dependencies
    • 🚨 :rotating_light: when removing linter warnings

JavaScript Styleguide

For a consistent codebase, we use ESLint and Prettier. This should already take most of the weight off of your sholders. In addition though:

  • Prefer the object spread operator ({...anotherObj}) to Object.assign()
  • Inline exports with expressions whenever possible 
    // Use this:
export default class ClassName {

}

// Instead of:
class ClassName {

}
export default ClassName