This document contains the rules and guidelines the developers are expected to follow while contributing to the repository.
The project was designed in Xcode 12.5 for iOS 14.0+, hence any issue that might be persisting in Xcode 13, iOS 15 can be resolved too, other than the said issues on Github.
- MongoDB Realm Studio. You can find the download link here. This might be helpful, if you'd like to improve the data model code.
- Fork the repository.
- Clone the project to your local machine.
- Checkout a new branch to work on an issue:
git checkout -b IssueNumber-GithubUsername
-
Create a pull request, once your issue is resolved to the
master
branch. -
For getting started on Git and its resources, you can find some tutorials and documentation here.
- Be descriptive with what exactly is the issue that you might have solved or worked with.
Example:
Valid commits:
- Add a Enhancer.swift for ContentView
- Updated LoginView for better Navigation
Invalid Commits:
- Solved a bug
- Ready for production
Issues can be opened if any of the below events occur:
- Code needs to be modified or refactored for better performance
- Feature enhancements
- Bugs encounter
-
No direct commit is to be made to the
main
branch directly. -
Follow the branch name as mentioned above,i.e.
IssueNumber-GithubUsername
-
Use kebab-casing for branch names.
Valid example:
- 7183-ameysunu
Invalid example:
- issue-7183-solved
- randomFix
-
Developers should be clear and concise while commenting on issues or PR reviews. If needed, provide visual reference or a code snippet to give more 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 write the code clearly and keep it as self documenting as possible. Use comments wherever necessary.
-
The project structure should be neat and organized. All folders and files should be organized 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