We welcome all contributions from folks who are willing to work in good faith with the community. No contribution is too small and all contributions are valued.
Issues in imusify/imusify-web
are the primary means by which bug reports and
general discussions are made. A contributor is allowed to create an issue,
discuss and provide a fix if needed.
Please join our Discord channel for general discussions/help.
Pull Requests are the way in which concrete changes are made to the code.
node
>=8
(LTS recommended)npm
Fork the project on GitHub and clone your fork locally.
git clone git@github.com:imusify/imusify-web.git
cd app
git remote add upstream https://github.com/imusify/imusify-web.git
git fetch upstream
It's always better to create local branches to work on a specific issue. Makes
life easier for you if you are the kind who enjoys multiple things parallely.
These should also be created directly off of the master
branch.
git checkout -b feature -t upstream/master
To keep the style of the Javascript code consistent we have a basic linting configured. To check your contributed code for errors and also to automatically fix them:
npm run lint
-
List all your changes as a list if needed else simply give a brief description on what the changes are.
-
All lines at 100 columns.
-
If your PR fixed an issue, Use the
Fixes:
prefix and the full issue URL. For other references useRefs:
.Examples:
Fixes: https://github.com/imusify/imusify-web/issues/1
Refs: https://github.com/imusify/imusify-web/issues/1
-
Sample commit A
if you can write down the changes explaining it in a paragraph which each line wrapped within 100 lines. Fixes: https://github.com/imusify/imusify-web/issues/1 Refs: https://github.com/imusify/imusify-web/issues/1
Sample commit B
- list out your changes as points if there are many changes - if needed you can also send it across as - all wrapped within 100 lines Fixes: https://github.com/imusify/imusify-web/issues/1 Refs: https://github.com/imusify/imusify-web/issues/1
-
Squashing and Merging your commits to make our history neater is always welcomed, but squashing can be handled during the merge process.
As a best practice, once you have committed your changes, it is a good idea
to use git rebase
(not git merge
) to ensure your changes are placed at the
top. Plus merge conflicts can be resolved
git fetch upstream
git rebase upstream/master
Please ensure that your pull request follows all of the community guidelines to include:
- Title is descriptive and generally focused on what the PR addresses (If your PR is a work in progress, include
WIP
in the title. Once the PR is ready for review, please removeWIP
) - Description explains what the PR achieves/addresses
- If the PR modifies the UI in any way, please attach screenshots of all purposeful changes (before and after screens are recommended)
- You must write unit tests for each new function, method and component you add and make sure you get to +90% test coverage. This is critical for high-quality code
- You must write integration tests for each new flow / feature you add or modeify
- You must make sure that all exisiting tests pass before submitting a new PR
- You must write UI tests for all new UI functionality