|
1 | | -## How to submit a contribution |
| 1 | +# Contributing Guidelines |
2 | 2 |
|
3 | | -Thank you for considering contributing to osc_sdk_python. |
| 3 | +First off, thank you for taking the time to contribute! 🙌 |
| 4 | +Your help is appreciated and helps make this project better for everyone. |
4 | 5 |
|
5 | | -Potential contributions include: |
| 6 | +--- |
6 | 7 |
|
7 | | -- Reporting and fixing bugs. |
8 | | -- Requesting features. |
9 | | -- Adding features. |
10 | | -- Cleaning up the code. |
11 | | -- Improving the documentation. |
| 8 | +## How to Contribute |
12 | 9 |
|
13 | | -In order to report bugs or request features, search the issue tracker to check for a duplicate. |
| 10 | +### 🐛 Reporting Bugs |
| 11 | +If you find a bug, please open an issue and include: |
| 12 | +- A clear and descriptive title |
| 13 | +- Steps to reproduce the issue |
| 14 | +- Expected and actual behavior |
| 15 | +- Any relevant logs, screenshots, or environment information |
14 | 16 |
|
15 | | -It’s totally acceptable to create an issue when you’re unsure whether |
16 | | -something is a bug or not. We’ll help you figure it out. |
| 17 | +### ✨ Suggesting Enhancements |
| 18 | +Have an idea for a new feature or improvement? |
| 19 | +- Open an issue and describe your suggestion |
| 20 | +- Explain the use case and potential benefits |
| 21 | +- Optional: propose an implementation strategy |
17 | 22 |
|
18 | | -Use the same issue tracker to report problems with the documentation. |
| 23 | +### 🛠️ Submitting Code Changes |
| 24 | +To submit a patch or enhancement: |
| 25 | +1. Fork the repository |
| 26 | +2. Create a new branch (`git checkout -b feature/your-feature-name`) |
| 27 | +3. Make your changes |
| 28 | +4. Test your changes (if applicable) |
| 29 | +5. Open a pull request with a clear description of your changes |
19 | 30 |
|
20 | | -## Pull Requests |
| 31 | +### ✅ Code of Conduct |
| 32 | +By participating, you agree to uphold our [Code of Conduct](CODE_OF_CONDUCT.md). |
21 | 33 |
|
22 | | -We’ll do our best to review your pull request (or “PR” for short) quickly. |
| 34 | +--- |
23 | 35 |
|
24 | | -Each PR should, as much as possible, address just one issue and be self-contained. |
25 | | -Smaller the set of changes in the pull request is, the quicker it can be reviewed and |
26 | | -merged - if you have ten small, unrelated changes, then go ahead and submit ten PRs. |
| 36 | +## Guidelines |
27 | 37 |
|
28 | | -Make sure to run tests/run.sh before each PR. |
| 38 | +- Keep pull requests focused and atomic (one feature or fix per PR). |
| 39 | +- Follow any existing code style or formatting conventions. |
| 40 | +- Document your code where necessary. |
| 41 | +- Include tests when adding new logic (if applicable). |
| 42 | +- Use clear, meaningful commit messages (optionally following [Conventional Commits](https://www.conventionalcommits.org/) and using [Gitmoji](https://gitmoji.dev/) for added clarity and consistency). |
29 | 43 |
|
30 | | -## How to release |
| 44 | +## 📝 Commit Template |
31 | 45 |
|
32 | | -- Update version in: |
33 | | - - [osc_sdk_python/VERSION](osc_sdk_python/VERSION) |
34 | | - - [README.md](README.md) |
35 | | -- Commit, PR, merge |
36 | | -- Create release in Github |
37 | | -- Github action should have generated artifacts. If not: |
38 | | - - `make package` |
39 | | - - Add `dist/osc_sdk_python-x.x.x-py3-none-any.whl` and `osc_sdk_python-x.x.x.tar.gz` files to release. |
40 | | - - Setup PIP_TOKEN and run `make upload-package` |
| 46 | +To help you follow the Gitmoji and Conventional Commit format, you can enable the local commit template: |
| 47 | + |
| 48 | +```bash |
| 49 | +git config commit.template .github/commit-template.txt |
| 50 | +``` |
| 51 | + |
| 52 | +--- |
| 53 | + |
| 54 | +## Questions? |
| 55 | + |
| 56 | +If you have any questions or need help, feel free to [open an issue](../../issues) or reach out to the maintainers on [Discord](https://discord.gg/HUVtY5gT6s). |
0 commit comments