Thank you for wanting to contribute to ListBot!
To start, please visit and read our Contributor Code of Conduct.
Welcome back! If you agree to abide by the Contributor Code of Conduct continue below, where you'll find an overview of the contributor workflow, contributor Dos & Don'ts, and a checklist for developers wanting to contribute to ListBot.
Here is a pictoral overview of the contributor workflow. Note that the workflow image uses a short branch name for illustrative purposes. Please name your issue branches according to the naming convention described later in this document.
Below is a step-by-step guide to the contributor workflow.
-
Fork the ListBot repo on GitHub
-
Clone the fork to your local machine.
$ git clone [email protected]:username/ListBot.git
-
Set up a remote
upstream
so that you can keep up to date with the source repository changes.$ git remote add upstream [email protected]:tomassirio/ListBot.git
You can verify you have set up the remote correctly by running the following command which will list the remote names and URLs:
$ git remote -v
You should see lines like the following two in the above command's output:
upstream [email protected]:tomassirio/ListBot.git (fetch) upstream [email protected]:tomassirio/ListBot.git (push)
-
Create a specific feature branch to develop on (be sure to branch off your up to date master branch):
$ git checkout -b ###-short-description-of-issue
The
###
in the branch name should match the number assigned to an open issue ticket within the ListBot repo on GitHub. For example, if you were working on Issue #142, the branch you create for your work might be named142-improve-contributor-docs
-
Edit and test the changes on your development machine.
-
Commit your work to your issue branch as needed.
-
Merge the upstream master branch (and fix any conflicts)
$ git fetch upstream $ git checkout master $ git merge upstream/master $ git checkout ###-short-description-of-issue # [make sure all is committed as necessary in branch before merging] $ git merge master
Get in the habit of continually incorporating changes from the upstream master to keep your master up-to-date as you work to avoid having to deal with many conflicts.
-
Perform final testing and run
npm run lint
to ensure there are no linting issues in your working branch. -
Push your issue branch up to your (origin) fork.
git push origin ###-short-description-of-issue
-
Issue a Pull Request on GitHub.
-
Before issuing a pull request be sure that you have: 1) incorporated the current state of the upstream master into your issue branch, 2) checked your code against the linter, and 3) tested ListBot with your changes in place.
-
As of this writing, there are no automated tests in the codebase. This means you must be diligent to ensure everything is in working order after making changes. You will do this by manually testing ListBot before issuing your pull request. This is not ideal, and there is an open issue for getting tests in place (help with that if you are able).
-
If you are adding a new feature, document how to test it in a PR comment. This is another stopgap until automated testing is in place, and at that time new features will require new automated tests exist as part of the pull request changes.
-
Don't develop on the master branch
-
Do create development branches for each issue you are working on
-
Do keep each development branch related to a single issue — do not mix fixes with features or unrelated fixes with other fixes; Open a new issue if you need to
-
Do keep config files clean (like .gitignore for example) — don't add test files that are specific to your setup
- Browse the list of issues in the repo and see if there is something you are interested in working on
- Or if you discover an issue with the bot or its documentation here open a new issue. If you are willing and able to fix the issue, note that in your submission and the issue will be assigned to you.