Skip to content

Latest commit

 

History

History
76 lines (49 loc) · 4.46 KB

CONTRIBUTING.md

File metadata and controls

76 lines (49 loc) · 4.46 KB

Contributing

Thank you for your interest in contributing to Eventbrite's Javascript SDK!

Table of Contents

Workflow

Setup

  1. This project uses yarn as a package management system. If you don't have it installed, you can follow the instructions here
  2. Fork the repository. need help?
  3. Clone your new forked repository to your local computer
  4. Set the Eventbrite repository as your branches upstream branch git remote add upstream https://github.com/eventbrite/eventbrite-sdk-javascript.git
  5. Navigate to the root directory of your newly cloned repository (for mac cd /path/to/eventbrite-sdk-javascript)
  6. yarn install to install local dependencies

Using branches to submit changes

To work on changes to the Eventbrite repository, create a new branch on your local repository. git checkout -b <your-new-branch-name>

Keeping your local repo up to date

To ensure your branch never gets out of sync with Eventbrite's master, ensure that you have your upstream set properly (see the Setup step)

  1. git checkout master (you may have to stash or commit your local changes if on a new branch)
  2. git pull upstream master
  3. git checkout <your-new-branch-name>
  4. git rebase master
  5. If you've stashed changes, unstash them now, otherwise your branch should now be up to date

Always try to keep your master 'clean' by only pulling changes directly from upstream into your master branch and rebasing those changes onto your working branch.

It is always a good idea to pull the upstream branch in to your master branch before creating a new feature branch to work from. This will minimize the chances of encountering merge conflicts.

Creating Issues

Create issues to file bugs, changes, and proposals.

Before opening a new issue, please search to see if there has been previous discussion about the same feature or issue. If so, please contribute to the discussion there.

If nothing is found, feel free to open a new issue and fill out the issue template to the best of your ability.

Working on and submitting changes

When starting on improvements or new features that are non-trivial, it is always a good idea to first discuss the changes you wish to implement by opening a github issue before getting started.

If you've found a bug or feature you'd like to work on in our github issue tracker, please comment on the issue to let others know that you'd like to work on it.

While implementing fixes, please try to change as little code as possible. This helps speed up the review process and helps diminish the chance of additional bugs.

Please try to conform to the coding style of the code base.

###Steps to submit:

  1. Please ensure that your changes are fully covered by one or more unit test(s).
  2. Check to make sure that your changes are documented properly (inline comments for interesting lines, READMEs, etc.)
  3. Run yarn validate to ensure that all tests pass, the linter is satisfied and your changes are typescript compliant.
  4. PR titles must be prefixed by the type of changes the PR contains followed by the scope of what the pr touches. We are following the angular commit guidelines. Please use one of feat, fix, docs, style, refactor, perf, test, chore as the prefix. The scope is the the direct product your changes affect. Example: chore(build): Add encrypted ssh key for semantic-release because its a chore and it touches the build.
  • For multiple scope items, you can comma separate 2 or 3 but if there are more than that please use a * instead.
  1. Please use a closing issue keyword to indicate the issue that your fix addresses in the description section of the pull request template. Example: fixes #32 to close issue #32