|
| 1 | +# TorchJD Governance |
| 2 | + |
| 3 | +This document defines the governance structure and decision-making process for the TorchJD project. |
| 4 | + |
| 5 | +## Maintainers |
| 6 | + |
| 7 | +TorchJD is maintained by: |
| 8 | + |
| 9 | +- **Valérian Rey** ([@ValerianRey](https://github.com/ValerianRey)) |
| 10 | +- **Pierre Quinton** ([@PierreQuinton](https://github.com/PierreQuinton)) |
| 11 | + |
| 12 | +Maintainers are responsible for: |
| 13 | +- Reviewing and merging pull requests |
| 14 | +- Managing releases |
| 15 | +- Setting project direction and priorities |
| 16 | +- Ensuring code quality and consistency |
| 17 | + |
| 18 | +## Decision Making |
| 19 | + |
| 20 | +### Technical Decisions |
| 21 | + |
| 22 | +Most technical decisions are made through the pull request process: |
| 23 | + |
| 24 | +1. **Minor changes** (bug fixes, documentation, small improvements): Require approval from at least one maintainer |
| 25 | +2. **Significant changes** (new features, API changes, refactoring): Should be discussed in an issue first, then require approval from at least one maintainer |
| 26 | +3. **Major changes** (breaking changes, architectural decisions): Should be discussed in an issue or discussion thread and require consensus from all maintainers |
| 27 | + |
| 28 | +### Pull Request Process |
| 29 | + |
| 30 | +1. Contributors submit pull requests following the guidelines in [CONTRIBUTING.md](CONTRIBUTING.md) |
| 31 | +2. Maintainers review the code for correctness, style, and alignment with project goals |
| 32 | +3. Once approved, any maintainer can merge the pull request |
| 33 | +4. All pull requests must pass CI checks before being merged |
| 34 | + |
| 35 | +### Consensus |
| 36 | + |
| 37 | +For major decisions, maintainers aim for consensus. If consensus cannot be reached: |
| 38 | +- The decision may be postponed for further discussion |
| 39 | +- If a decision must be made, the maintainer with the most relevant expertise in the area makes the final call |
| 40 | + |
| 41 | +## Release Process |
| 42 | + |
| 43 | +Releases are managed by maintainers following the process described in [CONTRIBUTING.md](CONTRIBUTING.md): |
| 44 | + |
| 45 | +1. Ensure all tests pass |
| 46 | +2. Update the changelog |
| 47 | +3. Update the version number |
| 48 | +4. Create a release on GitHub |
| 49 | +5. Verify deployment to PyPI |
| 50 | + |
| 51 | +## Adding Maintainers |
| 52 | + |
| 53 | +New maintainers may be added when: |
| 54 | +- They have made significant, sustained contributions to the project |
| 55 | +- They demonstrate understanding of the project's goals and coding standards |
| 56 | +- They are committed to the long-term maintenance of the project |
| 57 | + |
| 58 | +New maintainers must be approved by all existing maintainers. |
| 59 | + |
| 60 | +## Conflict Resolution |
| 61 | + |
| 62 | +Conflicts are resolved through discussion: |
| 63 | +1. Issues should first be discussed in the relevant issue or pull request |
| 64 | +2. If unresolved, maintainers discuss privately to reach consensus |
| 65 | +3. The goal is always to find the best solution for the project and its users |
| 66 | + |
| 67 | +## Code of Conduct |
| 68 | + |
| 69 | +This project follows the [Linux Foundation Code of Conduct](https://lfprojects.org/policies/code-of-conduct/). |
| 70 | + |
| 71 | +## Changes to Governance |
| 72 | + |
| 73 | +Changes to this governance document require approval from all maintainers. |
0 commit comments