|
| 1 | +# Contributing |
| 2 | + |
| 3 | +Thank you for your interest in contributing to our project! This guide will help you get started with contributing effectively. |
| 4 | + |
| 5 | +## Code of Conduct |
| 6 | + |
| 7 | +We expect all contributors to follow our Code of Conduct. Please be respectful and constructive in all interactions. |
| 8 | + |
| 9 | +## Getting Started |
| 10 | + |
| 11 | +1. Fork the repository |
| 12 | +2. Clone your fork locally |
| 13 | +3. Create a new branch for your changes |
| 14 | +4. Make your changes |
| 15 | +5. Push to your fork |
| 16 | +6. Submit a pull request |
| 17 | + |
| 18 | +## Development Process |
| 19 | + |
| 20 | +1. Check existing issues or create a new one to discuss proposed changes |
| 21 | +2. Fork the repository and create your branch from `main` |
| 22 | +3. Make your changes following our coding standards |
| 23 | +4. Add or update tests as needed |
| 24 | +5. Update documentation if required |
| 25 | +6. Ensure all tests pass locally |
| 26 | +7. Submit a pull request |
| 27 | + |
| 28 | +## Commit Guidelines |
| 29 | + |
| 30 | +We follow [Conventional Commits](https://www.conventionalcommits.org/) specification for commit messages. This leads to more readable messages that are easy to follow when looking through the project history. |
| 31 | + |
| 32 | +## Pull Request Process |
| 33 | + |
| 34 | +- Ensure your pull request (PR) is focused on a single topic or issue. |
| 35 | +- Reference any relevant issues in your PR description (e.g., "Closes #123"). |
| 36 | +- Provide a clear summary of your changes and the motivation behind them. |
| 37 | +- Ensure your code passes all tests and adheres to our coding standards. |
| 38 | +- Be responsive to feedback and make requested changes promptly. |
| 39 | +- PRs will be reviewed by maintainers and may require approval from multiple reviewers before merging. |
| 40 | + |
| 41 | +## Issue Reporting |
| 42 | + |
| 43 | +- Search existing issues before opening a new one to avoid duplicates. |
| 44 | +- Provide a clear and descriptive title. |
| 45 | +- Include steps to reproduce, expected behavior, and actual behavior. |
| 46 | +- Attach logs, screenshots, or code snippets if helpful. |
| 47 | +- Be respectful and constructive in your communication. |
| 48 | + |
| 49 | +## Coding Standards |
| 50 | + |
| 51 | +- Follow the language-specific style guides (e.g., PEP8 for Python, ESLint for JavaScript). |
| 52 | +- Write clear, maintainable, and well-documented code. |
| 53 | +- Include type annotations and docstrings/comments where appropriate. |
| 54 | +- Avoid introducing breaking changes unless discussed and approved. |
| 55 | + |
| 56 | +## Documentation |
| 57 | + |
| 58 | +- Update documentation for any user-facing changes. |
| 59 | +- Ensure code examples are up-to-date and accurate. |
| 60 | +- Use clear and concise language. |
| 61 | +- Follow the existing documentation structure and style. |
| 62 | + |
| 63 | +## Community Support |
| 64 | + |
| 65 | +- Join discussions in our community channels ([GitHub](https://github.com/forepath/obms-module-sdk/discussions) and [Discord](https://discord.gg/5wFMuVvQZM)). |
| 66 | +- Help others by answering questions and reviewing PRs. |
| 67 | +- Respect differing viewpoints and foster a welcoming environment. |
| 68 | + |
| 69 | +--- |
| 70 | + |
| 71 | +Thank you for helping us improve this project! Your contributions make a difference. |
0 commit comments