We use a fork-and-PR process, also known as a triangular workflow. This process is fairly common in open-source projects. Here's the basic workflow:
- Fork the upstream repo to create your own repo. This repo is called the origin repo.
- Clone the origin repo to create a working directory on your local machine.
- Work your changes on a branch in your working directory, then add, commit, and push your work to your origin repo.
- Submit your changes as a PR against the upstream repo. You can use the upstream repo UI to do this.
- Maintainers review your changes. If they ask for changes, you work on your origin repo's branch and then submit another PR. Otherwise, if no changes are made, then the branch with your PR is merged to upstream's main trunk, the main branch.
When you work in a triangular workflow, you have the upstream repo, the origin
repo, and then your working directory (the clone of the origin repo). You do
a git fetch from upstream to local, push from local to origin, and then do a PR from origin to
upstream—a triangle.
If this workflow is too much to understand to start, that's ok! You can use GitHub's UI to make a change, which is autoset to do most of this process for you. We just want you to be aware of how the entire process works before proposing a change.
Thank you for your contributions; we appreciate you!
Note that we use a standard MIT license on this repo.
Code style is enforced by eslint. Linting is applied CI builds when a pull request is made. The rule set being enforced is provided by eslint-config-logdna
The easiest way to get our attention is to comment on an existing, or open a new issue.