Skip to content

Latest commit

 

History

History
161 lines (113 loc) · 4.64 KB

CONTRIBUTING.md

File metadata and controls

161 lines (113 loc) · 4.64 KB
Raw

Contributors guidelines

Introduction

Thank you for your interest in contributing to this project! Your contributions help make this project better for everyone. These guidelines will help you understand how to contribute to the repository.

How to Contribute

Reporting issues

  1. Search Existing Issues: Before opening a new issue, please check if the issue has already been reported. Duplicate issues take time to manage and can clutter the tracker.

  2. Creating a New Issue: If you find a new bug or have a feature request, please open an issue using the provided templates. Be as descriptive as possible. Include steps to reproduce the issue, the expected result, and any relevant screenshots or logs.

Contributing code

  1. Fork the Repository: Fork the repository to your own GitHub account and clone it to your local machine.

  2. Create a Branch: Create a new branch for your work. Use a descriptive name for your branch (e.g., feat-add-new-feature or fix-issue-123).

  3. Write Tests: If your contribution includes code, please write tests to ensure your changes are robust and maintainable.

  4. Commit Changes: Make your changes in your branch. Commit your changes with clear and concise commit messages.

  5. Push Changes: Push your changes to your forked repository.

  6. Create a Pull Request: Open a pull request from your forked repository to the main repository. Fill out the pull request template, describing your changes and linking to any relevant issues.

Commit messages

Clear and structured commit messages help in understanding the history of the project. Use the following prefixes to categorize your commits:

  • feat: A new feature (e.g., feat: add user authentication).

  • fix: A bug fix (e.g., fix: resolve null pointer exception on login).

  • docs: Documentation only changes (e.g., docs: update contributing guidelines).

  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.) (e.g., style: format code according to style guide).

  • refactor: A code change that neither fixes a bug nor adds a feature (e.g., refactor: optimize user data processing).

  • test: Adding missing or correcting existing tests (e.g., test: add unit tests for user service).

  • chore: Miscellaneous commits (e.g., chore: modifying .gitignore).

Code style

  1. Follow the Coding Standards: Ensure your code adheres to the project’s coding standards and guidelines.

  2. Linting: Use the project’s configured linter to check your code for style issues before submitting.

  3. Documentation: Update the documentation to reflect your changes if they affect the public API or usage instructions.

Testing guidelines

Unit Testing

  • Write Unit Tests: Write unit tests for your code to ensure it works as expected.

  • Use a Testing Framework: Use Confirma to write and run your tests.

  • Test Edge Cases: Test edge cases and error scenarios to ensure your code is robust.

  • Keep Tests Independent: Keep your tests independent and focused on a specific piece of functionality.

End-to-End (E2E) Testing

  • Write E2E Tests: Write E2E tests to ensure your code works as expected in a real-world scenario.

  • Use a Testing Framework: Use Bun runtime to write and run your E2E tests.

  • Test User Flows: Test user flows and interactions to ensure your code works as expected.

  • Keep E2E Tests Focused: Keep your E2E tests focused on a specific user flow or scenario.

Editor configuration

To maintain consistency in coding styles, please use an editor that supports the .editorconfig file included in the repository. This file helps maintain consistent coding styles between different contributors and editors. Most popular editors have plugins or built-in support for .editorconfig.

Review process

  1. Review: All contributions will be reviewed by project maintainers. Be responsive to feedback and be prepared to make necessary changes.

  2. Approval: Once your changes are approved, they will be merged into the main branch. You will receive a notification when this happens.

Community guidelines

  1. Be Respectful: Respect all community members and their contributions. Be constructive and courteous in your communications.

  2. Inclusivity: Strive to create an inclusive environment for everyone, regardless of background, gender, or experience level.

  3. Help Others: If you can help others with their issues or pull requests, please do so. A collaborative community is a strong community.

License

By contributing, you agree that your contributions will be licensed under the project’s open-source license.