Before you start contributing it's useful to know about philosophy and general contributing guidelines.
Your commits will be merged to master
branch under your name. Few of earlier commits have been squashed and rebased from epic/feature branches on GitHub because of my settings. These settings have been switched off.
-
It's always better to be a good and easy going person rather than "I know how to do sh*t" kind of person.
-
It doesn't matter how much years of experience do you have, ask questions, get answers, communicate, collaborate, follow guidelines (see below).
-
Code quality bar is quite high (comparing to other FOSS projects), please expect code reviews, rejects, change requests.
-
It's always better to ask before you do a big amount of work. Usually PRs should be very focused and should fix specific issue or add one feature at a time.
-
Do not hurry. Give a time, think about the right way to implement stuff. Get some coffee.
-
But after all, we would love to see your changes!
- Write tests.
- Run linter against your
src
andtests
(runs automatically when younpm test
). - Try to avoid compound variable names, method names, class names as much as you can. Good:
count
. Bad:orderCount
. If you're about using long variable name, try to break your scope into smaller scopes. - No files with more than 250 lines of code. Try to limit line count to 200.
- Document your methods, classes with esdoc (see already existing code for examples).
- Make documentation clean, keep it short and meaningful.
- Before you do any work, create GitHub issue. Give a good explanation of the story you gonna work on. Show examples. It can be obvious for you, but not for others. Save time one should spend understanding your changes. Add screenshots, pics if needed.
- Branch from the
master
(Example:git checkout -b 123-blabla
). Name your branches the right way:NNN-short-branch-description
. WhereNNN
is GitHub issue number. Andshort-branch-description
is short and meaningful description of the work you gonna do. It's better to have 1 word description than 5. - Always prefix your commits with
# NNN
whereNNN
is GitHub issue number. For example:#123 Add blabla to something
. Keep in mind that#
is usually comment symbol in Git. So you may want to usegit commit -m "#123 Add blabla to something"
shell command or configure your~/.gitconfig
. - Use right wording for your Git commits. Make them meaningful, short, use imperative mood (see good explanation here).
- Use
#NNN
prefix when you create PR. PR subject line should reflect your changes, should be meaningful and short. - Feel free to ask for advice (mention
@ro31337
) if you need help with approach. - (recommendation) When work is done, test your feature/bug, add screenshots confirming everything works as expected. It can be obvious for you, but here you want to save time for others.