-
Notifications
You must be signed in to change notification settings - Fork 12
Contribution Guidelines
Developers looking to contribute to the project can start by filtering for good-first-issues tags from issues tracker.
It is requested that developers MUST assign themselves the issue that they wish to work. To avoid any confusion with task allocation.
Currently Git repo contains master and dev branch.
The master branch contains the production-ready code that is ready to be deployed.
NOTE: To keep sanity in check, master branch will be managed by authorized members, who will be working on the release/deployment process.
For contributors, we have a dev branch with the latest features and fixes. We request you to create a new branch for the Issue you are working on from the dev branch.
New branch name must follow following format: issue-{issue_number}-{relative-subject}
Example: If you are working on issue number 10 which requires to work on login page sign up button UI changes. Then new branch name should be " issue-10-update-sign-up-btn-login-page "
It is always recommended to follow good practices and standards while coding to achieve better code readability and to enhance the chance of comprehensive structure when working in this collaborative environment.
Few helpful link:
Javascript(reactjs, nextjs)
- https://developer.mozilla.org/en-US/docs/MDN/Guidelines/Code_guidelines/JavaScript
- https://www.w3.org/wiki/JavaScript_best_practices
CSS/Sass/Scss
Branch commit message/s provides overview for the changes in current branch. So Using conventional commit rules provides a clear, precise and comprehensive gist of work done to other collaborators/contributors. It also helps to manage changelog and sanity in check.
In general, the pattern mostly looks like this:
<type>(<scope>?): <subject>
type: Types of commit messages:
- build : Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
- ci: Changes to CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs,vercel)
- docs: Documentation only changes
- feat: A new feature
- fix: A bug fix
- perf: A code change that improves performance
- refactor: A code change that neither fixes a bug nor adds a feature
- revert: commit point is revert to previous branch commit
- style: Changes related to styles, design or which do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- test: Adding missing tests or correcting existing tests
Scope: The candidates for scope depend on the project and the technologies being used. Here we can use the issue number we are working on. Eg: issue-10
Subject: The subject contains a succinct description of the change:
- use the imperative, present tense: “change” not “changed” nor “changes”
- don’t capitalize the first letter
- no dot/period (.) at the end
Real world example can look like this:
git commit -m “feat(issue-10): add comment section"
To know more follow up this link: https://www.conventionalcommits.org/en/v1.0.0/
Once commit is pushed to GitHub, it is requested you to raise pull-request in github, where keeping the base branch as dev branch.
Other members will review by assigning themselves as reviewer to Pull requests. Once code review is done, we will merge the requested branch with the dev branch.