Thanks for taking the time to reach this far! It's great to see that you're as interested in this project as I am. 😄 Here you'll find everything you need to know to contribute to this project. This project is made by people for people, so, by following this guidelines, you help your peer developers help you developing the new features you have in mind or fixing the bugs or issues you find. Of course, all the help is appreciated, from code to docs, even by recommending this project you're helping!
Also, this project is ruled by Contributor Convenant's code of conduct.
Would you like to contribute but you're just not sure where to start? Check out the open issues
Working on your first Pull Request? You can learn how from this free series, How to Contribute to an Open Source Project on GitHub.
If through the whole process of contributing you have any doubt, do not hesitate to contact me or any of the contributors: We're all here to learn and help! 🤓
Now, the fun part! (Based on Node JS contribution guide)
Fork the project on GitHub and clone your fork in your local.
$ git clone git@github.com:username/JEasyCrypto.git
$ cd sbotify
$ git remote add upstream https://github.com/a-rmz/JEasyCrypto.git
The master branch holds the latest release code, so for development and bug fixing, develop is your way to go.
Create a branch and start hacking:
$ git checkout -b my-branch -t origin/develop
Make sure git knows your name and email address:
$ git config --global user.name "J. Random User"
$ git config --global user.email "j.random.user@example.com"
Add and commit:
$ git add my/changed/files
$ git commit
To avoid this:
The commit message should describe what changed and why. Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug." This convention matches up with commit messages generated by commands like git merge and git revert.
-
The first line should:
- start with a capital letter
- contain a short description of the change
- be 50 characters or less
- be entirely in lowercase with the exception of proper nouns, acronyms, and the words that refer to code, like function/variable names
-
Keep the second line blank.
-
Wrap all other lines at 72 columns.
-
If your patch fixes an open issue, you can add a reference to it at the end of the log. Use the
Fixes:prefix and the full issue URL. For other references useRefs:.Examples:
Fixes: https://github.com/nodejs/node/issues/1337Refs: http://eslint.org/docs/rules/space-in-parens.htmlRefs: https://github.com/nodejs/node/pull/3615
Sample complete commit message:
explain the commit in one line
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, followed by a
single space, with blank lines in between, but conventions vary here
- Use a hanging indent
Fixes: https://github.com/nodejs/node/issues/1337
Refs: http://eslint.org/docs/rules/space-in-parens.htmlUse git rebase (not git merge) to synchronize your work with
the main repository.
$ git fetch upstream
$ git rebase upstream/develop
$ git push origin my-branch
You will probably get feedback or requests for changes to your Pull Request. This is a big part of the submission process so don't be discouraged!
To make changes to an existing Pull Request, make the changes to your branch. When you push that branch to your fork, GitHub will automatically update the Pull Request.
You can push more commits to your branch:
$ git add my/changed/files
$ git commit
$ git push origin my-branch
Or you can rebase against develop:
$ git fetch --all
$ git rebase origin/develop
$ git push --force-with-lease origin my-branch
Or you can amend the last commit (for example if you want to change the commit log).
$ git add any/changed/files
$ git commit --amend
$ git push --force-with-lease origin my-branch
Feel free to post a comment in the Pull Request to ping reviewers if you are awaiting an answer on something. If you encounter words or acronyms that seem weird, check this glossary.
In order to land, a Pull Request needs to be reviewed and approved by at least one Collaborator. After that, as long as there are no objections from a Collaborator, the Pull Request can be merged.
A Pull Request is approved either by saying LGTM, which stands for "Looks Good To Me", or by using GitHub's Approve button. GitHub's Pull Request review feature can be used during the process. For more information, check out the video tutorial or the official documentation.
After you push new changes to your branch, you need to get approval for these new changes again, even if GitHub shows "Approved" because the reviewers have hit the buttons before.
If you find a security vulnerability, do NOT open an issue. Email me instead.
If you want to report a bug or issue, go to the
new issue section and fill the template.
Also, add the tag bug.
If you'd like a feature to be added, fill an issue describing what would you like
the new feature to do and tag it as feature-suggestion. Be as descriptive as possible!
A best description will make it clearer for other people to understand what you want
and help you achieve it. 😉