This project adheres to the Contributor Covenant code of conduct. By participating, you are expected to uphold this code. Please see our [Code of Conduct][code-of-conduct] for details on reporting unacceptable behavior.
**Working on your first Pull Request?**
[How to Contribute to an Open Source Project on GitHub][egghead]
## How do
* Project setup?
[We've got you covered!](#project-setup)
* Found a bug?
[Let us know!][new-issue]
* Patched a bug?
[Make a PR!][new-pr]
* Adding a new feature?
Make sure to [open an issue][new-issue] describing your feature, then open a [new PR][new-pr] when you're ready for feedback!
## Project setup
We're really happy you want to contribute to the project! ❤️ The following steps will get you up and running:
> This will add the original repository as a "remote" called "upstream," fetch the git information from that remote, and set your local `master` branch to use the `upstream/master` branch whenever you run `git pull`. At that point, you can create all of your branches from this `master` branch. Whenever you want to update your version of `master`, do a regular `git pull`.
## Contributing for members of the `nostalgic-css` organization
Below are steps which must be followed by the members of the `nostalgic-css` organization. External collaborators only have to follow the above guidelines.
### Steps for development
1. Branch from `develop` using the formatting rules below.
2. Do the work required to satisfy the issue. If you identify work that is unrelated to the issue, please [create a new issue][new-issue] and do the work on a separate branch.
3. Submit your PRs to merge back into `develop`.
* Any change which would affect current development should be documented in the description.
* PRs with an issue should be include that issue's number in the title. IE: `[#33] Fix bug`
* Assign the PR to yourself.
* When the PR is ready to be merged, A review should be requested from the `nostalgic-css/NES.css` team.
4. Once the PR is approved, it is the responsibility of the **assignee** to merge the changes to the branch.
### Commit formatting
We use [Commitizen][commitizen] and [`commitlint`][commitlint] to make sure all of the commits to the project are easy to read, and [`semantic-release`][semantic-release] to ensure that our releases are automated, [unromantic, and unsentimental][sentimental-versioning].