Pull Request

Before submitting, please make sure that:

• Keep it simple: At least (~300 lines of diff). Keep your changes focused and addressing one issue per PR. Otherwise, please split it into separate requests.
• Make it clear: Write clear and concise commit messages and PR descriptions.
• Pass all tests: Test your changes thoroughly and ensure they don't introduce any regressions.

Guidelines

• Follow the existing code style and formatting conventions.
• Keep your changes focused and atomic, addressing one issue per PR.
• Write clear and concise commit messages and PR descriptions.
• Test your changes thoroughly and ensure they don't introduce any regressions.
• Be respectful and considerate towards other contributors.

Code Conventions

Contributors must follow the standard code style and formatting conventions. Check out this guide to learn more.

Semantic commit messages follow a specific format that typically includes a type, an optional scope, and a description. The basic structure is:

<type>(<scope>): <subject>

scopes is optional. Consider adding a scope if the change affects a specific area, such as a module or component. It should be brief yet recognizable, e.g. docs, core.

Example

feat(core): add search to website
^--^^----^  ^-------------------^
|   |       |
|   |       +-> Summary in present tense. Use lower case, not title case!
|   |
|   +-> The package(s) that this change affected.
|
+-------> Type: see above for the list we use.

Type	Description	Example Commit message
feat	A new API or behavior for the end user.	allow users to upload profile pictures.
fix	A bug fix for the end user.	fix mobile login button click issue.
docs	A change to the website or other Markdown documents in our repo.	update installation guide with troubleshooting steps.
refactor	A change to production code that leads to no behavior difference.	enhance code readability and maintainability.
test	Adding missing tests, refactoring tests; no production code change.	add unit tests for user authentication module.
chore	Upgrading dependencies, releasing new versions, maintenance tasks.	update package.json with latest dependency versions.
misc	Anything else that doesn't change production code, yet is not test or chore.	update GitHub Actions workflow to include code linting.

More about Conventional Commits.

Fork

1. Fork the repository to your GitHub account.
2. Clone the forked repository to your local machine.
3. Create a new branch for your feature or bug fix:

git switch -c <'feature/your-feature-name'>

4. Make your changes and commit them with descriptive commit messages:

git commit -m 'feat:Add some feature'

5. Push your changes to your forked repository:

git push -u origin <'feature/your-feature-name'>

6. Open a pull request (PR) against the main repository's main branch.
7. Ensure that your PR includes a clear description of the changes made and any relevant information.
8. Our team will review your PR, provide feedback, and merge it if everything looks good.