This document contains certain rules and guidelines that developers are expected to follow, while contributing to any repository by @Abhi6722.
-
Use the
-m
flag only for minor changes. The message following the-m
flag must be of the below format :<Verb>: <Action>
Verbs oftenly used are
- add
- feat
- fix
- refactor
✅ Examples of valid messages:
- add: serialisers.py for users app
- feat: validation
- fix: functionality of authentication process
- refactor: remove unwanted comments from src/auth.ts
❌ Examples of invalid messages:
- Idk why this is not working
- Only ui bug fixes left
- All changes done, ready for production :))
-
Before opening a PR, make sure you squash all your commits into one single commit using
git rebase
(squash). Instead of having 50 commits that describe 1 feature implementation, there must be one commit that describes everything that has been done so far. You can read up about it here.NOTE: While squashing your commits to write a new one, do not make use of
-m
flag. In this case, a vim editor window shall open. Write a title for the commit within 50-70 characters, leave a line and add an understandable description.
- Issues MUST be opened any time any of the following events occur:
- You want feature enhancements.
- You encounter bugs.
- Code refactoring is required.
- Test coverage should be increased.
- Open issues with the given template only.
- Feel free to label the issues appropriately.
- Do not remove the headings (questions in bold) while opening an issue with the given template. Simply append to it.
-
No commits must be made to the
main
/master
branch directly. Themain
/master
branch shall only consist of the working code. -
Developers are expected to work on feature branches, and upon successful development and testing, a PR (pull request) must be opened to merge with
main
/master
. -
A branch must be named as either as the feature being implemented, or the issue being fixed.
✅ Examples of valid brach names:
- #8123 (issue number)
- OAuth (feature)
- questionsUtils (functionality of the questions)
❌ Examples of invalid branch names:
- ziyan-testing
- attemptToFixAuth
- SomethingRandom
- Developers should be clear and concise while commenting on issues or PR reviews. If needed, one should provide visual reference or a code snippet for everyone involved to properly grasp the context.
- Everyone should be respectful of everyone's opinion. Any harsh/disrespectful language is STRICTLY prohibited and will not be tolerated under any circumstances.
- Developers are highly encouraged to use comments wherever necessary and make the code self documented.
- The project structure should be neat and organised. All folders and files should be organised semantically according to their functionality.
- The name of the folders and files should not be too long but should be as self explanatory as possible.
- Documentation shall STRICTLY have gender neutral terms. Instead of using "he/him" or "she/her", one should use "they/them" or "the user".
Developers should aim to write clean, maintainable, scalable and testable code. If your code is not testable, that means, it's time to refactor it. The following guidelines might come in handy for this:
- Python: Hitchiker's Guide to Python, Google
- GoLang: Effective-Go
- Django: Django-Styleguide
- JavaScript: Airbnb
- React.JS: Airbnb
- Flutter/Dart: Effective-Dart
- Kotlin: Kotlin Conventions
- Swift: Swift Style Guide, Google
- Docker: Dev Best Practices, Dockerfile Best Practices