## What do I need to know to help?

You'll need knowledge of JavaScript (ES6), React, RxJS, and CSS to help out
with this project.

## How do I make a contribution?

Never made an open source contribution before? Wondering how contributions work
in the nteract world? Here's a quick rundown!

1. Find an issue that you are interested in addressing or a feature that you
would like to address.
2. Fork the repository associated with the issue to your local GitHub organization.
3. Clone the repository to your local machine using `git clone
https://github.com/github-username/repository-name.git`.
4. Create a new branch for your fix using `git checkout -b branch-name-here`.
5. Make the appropriate changes for the issue you are trying to address or the
feature that you want to add.
6. Add and commit the changed files using `git add` and `git commit`.
7. Push the changes to the remote repository using `git push origin
branch-name-here`.
8. Submit a pull request to the upstream repository.
9. Title the pull request with "Problem: issue or feature addressed".
10. Set the description of the pull request with "Solution: fix provided or
feature added".
11. Wait for the pull request to be reviewed by a maintainer.
12. Make changes to the pull request if the reviewing maintainer recommends them.
13. Celebrate your success after your pull request is merged! :tada:

## What does C4.1 mean for me?

You might not have heard of C4.1, or the Collective Code Construction Contract.
Have no fear! Here's a quick rundown of what C4.1 means for you as a contributor.
* Everyone can be a contributor to the project.
* A contributor who has a pull request successfully merged can be invited to be
a maintainer.
* Maintainers have the ability to review and merge pull requests.

## How should I write my commit messages and PR titles?

Great question! Here at nteract, we utilize the [conventional-changelog-standard]
(https://github.com/bcoe/conventional-changelog-standard/blob/master/convention.md)
for writing our commit messages and PR titles. Why do we do this? The standard
comes in really handy when we need to determine what kinds of information should
go into our release documentation (as the word changelog in the title might suggest!).
Good release messages means more informed users means a better project to use. Yay!

That's it! You're good to go!
