Skip to content

Latest commit

 

History

History
executable file
·
125 lines (91 loc) · 4.39 KB

CONTRIBUTING.md

File metadata and controls

executable file
·
125 lines (91 loc) · 4.39 KB
Raw

Contributing

We love pull requests from everyone.

The following are a set of guidelines to follow when contributing to this project.

Code Of Conduct

This project adheres to the Adobe code of conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to Grp-opensourceoffice@adobe.com.

Have A Question?

Start by filing an issue. The existing committers on this project work to reach consensus around project direction and issue solutions within issue threads (when appropriate).

Security Issues

Security issues shouldn't be reported on this issue tracker. Instead, file an issue to our security experts.

Contributor License Agreement

All third-party contributions to this project must be accompanied by a signed contributor license agreement. This gives Adobe permission to redistribute your contributions as part of the project. Sign our CLA. You only need to submit an Adobe CLA one time, so if you have submitted one previously, you are good to go!

Code Reviews

All submissions should come in the form of pull requests and need to be reviewed by project committers.

Start by forking the repo, then clone your fork:

git clone git@github.com:yourusername/coral-spectrum.git

Set up a branch for your feature or bug fix, push it to your fork, and set up a remote for the upstream repo:

git checkout -b my-awesome-new-feature
git push -u origin my-awesome-new-feature
git remote add upstream git@github.com:adobe/coral-spectrum.git

Install dependencies:

npm install

Make sure the gulp-cli is installed globally:

npm install -g gulp-cli

Build the project, open a browser window, and watch for changes:

gulp

Commit changes, referencing the relevant issue number (if any):

git commit -m "Cool stuff, closes #250, fixes #252"

Consider starting the commit message with an applicable emoji:

  • 🎨 :art: when improving the format/structure of the code
  • ⚡ :zap: when improving performance
  • 🚱 :non-potable_water: when plugging memory leaks
  • 📝 :memo: when writing docs
  • 🚑 :ambulance: a critical hotfix.
  • ✨ :sparkles: when introducing new features
  • 🔖 :bookmark: when releasing / version tags
  • 🚀 :rocket: when deploying stuff
  • 🐧 :penguin: when fixing something on Android
  • 🍎 :apple: when fixing something on iOS
  • 🏁 :checkered_flag: when fixing something on Windows
  • 🐛 :bug: when fixing a bug
  • 🔥 :fire: when removing code or files
  • 💚 :green_heart: when fixing the CI build
  • ✅ :white_check_mark: when adding tests
  • 🔒 :lock: when dealing with security
  • ⬆️ :arrow_up: when upgrading dependencies
  • ⬇️ :arrow_down: when downgrading dependencies
  • 👕 :shirt: when removing linter warnings
  • 🔨 :hammer: when doing heavy refactoring
  • ➖ :heavy_minus_sign: when removing a dependency.
  • ➕ :heavy_plus_sign: when adding a dependency.
  • 🔧 :wrench: when changing configuration files.
  • 🌐 :globe_with_meridians: when dealing with internationalization and localization.
  • ✏️ :pencil2: when fixing typos.
  • 💩 :hankey: when writing bad code that needs to be improved.
  • 📦 :package: when updating compiled files or packages.

Make sure your branch is up to date with the original repo:

git fetch upstream
git merge upstream/master

Review your changes and any possible conflicts and push to your fork:

git push origin

Submit a pull request.

At this point you're waiting on us. We do our best to keep on top of all the pull requests. We may suggest some changes, improvements or alternatives.

Some things that will increase the chance that your pull request is accepted:

  • Write a good commit message.
  • Make sure the PR merges cleanly with the latest master.
  • Describe your feature/bugfix and why it's needed/important in the pull request description.