|
| 1 | +# Contributors |
| 2 | + |
| 3 | +The project differentiates between 3 levels of contributors: |
| 4 | + |
| 5 | +- Contributors: people who have contributed before (no special privileges) |
| 6 | +- Collaborators (Triage): people with significant contributions, who may be responsible for some parts of the code, and are expected to maintain and review contributions for the code they own |
| 7 | +- Maintainers: responsible for reviewing and merging PRs, after approval from the code owners |
| 8 | + |
1 | 9 | # Pull requests (for contributors) |
2 | 10 |
|
3 | 11 | - llama.cpp uses the ggml tensor library for model evaluation. If you are unfamiliar with ggml, consider taking a look at the [examples in the ggml repository](https://github.com/ggml-org/ggml/tree/master/examples/). [simple](https://github.com/ggml-org/ggml/tree/master/examples/simple) shows the bare minimum for using ggml. [gpt-2](https://github.com/ggml-org/ggml/tree/master/examples/gpt-2) has minimal implementations for language model inference using GPT-2. [mnist](https://github.com/ggml-org/ggml/tree/master/examples/mnist) demonstrates how to train and evaluate a simple image classifier |
|
12 | 20 |
|
13 | 21 | # Pull requests (for collaborators) |
14 | 22 |
|
| 23 | +- Maintainers will rely on your insights and approval when making a final decision to approve and merge a PR |
| 24 | +- Consider adding yourself to [CODEOWNERS](CODEOWNERS) to indicate your availability for reviewing related PRs |
| 25 | + |
| 26 | +# Pull requests (for maintainers) |
| 27 | + |
15 | 28 | - Squash-merge PRs |
16 | 29 | - Use the following format for the squashed commit title: `<module> : <commit title> (#<issue_number>)`. For example: `utils : fix typo in utils.py (#1234)` |
17 | 30 | - Optionally pick a `<module>` from here: https://github.com/ggml-org/llama.cpp/wiki/Modules |
18 | | -- Consider adding yourself to [CODEOWNERS](CODEOWNERS) |
19 | | -- Let authors, who are also collaborators, merge their own PRs |
| 31 | +- Let other maintainers, merge their own PRs |
20 | 32 | - When merging a PR by a contributor, make sure you have a good understanding of the changes |
21 | 33 | - Be mindful of maintenance: most of the work going into a feature happens after the PR is merged. If the PR author is not committed to contribute long-term, someone else needs to take responsibility (you) |
22 | 34 |
|
|
117 | 129 | #endif // FOO |
118 | 130 | ``` |
119 | 131 |
|
| 132 | +# Code maintenance |
| 133 | +
|
| 134 | +- Existing code should have designated collaborators and/or maintainers specified in the [CODEOWNERS](CODEOWNERS) file reponsible for: |
| 135 | + - Reviewing and merging related PRs |
| 136 | + - Fixing related bugs |
| 137 | + - Providing developer guidance/support |
| 138 | +
|
| 139 | +- When adding or modifying a large piece of code: |
| 140 | + - If you are a collaborator, make sure to add yourself to [CODEOWNERS](CODEOWNERS) to indicate your availability for reviewing related PRs |
| 141 | + - If you are a contributor, find an existing collaborator who is willing to review and maintain your code long-term |
| 142 | + - Provide the necessary CI workflow (and hardware) to test your changes |
| 143 | +
|
| 144 | +- New code should follow the guidelines (coding, naming, etc.) outlined in this document. Exceptions are allowed in isolated, backend-specific parts of the code that do not interface directly with the `ggml` interfaces. |
| 145 | + _(NOTE: for legacy reasons, existing code is not required to follow this guideline)_ |
| 146 | +
|
120 | 147 | # Documentation |
121 | 148 |
|
122 | 149 | - Documentation is a community effort |
|
0 commit comments