| 
1 |  | -# Pull requests (for contributors)  | 
 | 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 | + | 
 | 9 | +# Pull requests (for contributors & collaborators)  | 
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  | 
4 | 12 | - Test your changes:  | 
 | 
9 | 17 | - Create separate PRs for each feature or fix. Avoid combining unrelated changes in a single PR  | 
10 | 18 | - Consider allowing write access to your branch for faster reviews, as reviewers can push commits directly  | 
11 | 19 | - If your PR becomes stale, don't hesitate to ping the maintainers in the comments  | 
 | 20 | +- Maintainers will rely on your insights and approval when making a final decision to approve and merge a PR  | 
 | 21 | +- Consider adding yourself to [CODEOWNERS](CODEOWNERS) to indicate your availability for reviewing related PRs  | 
12 | 22 | 
 
  | 
13 |  | -# Pull requests (for collaborators)  | 
 | 23 | +# Pull requests (for maintainers)  | 
14 | 24 | 
 
  | 
15 | 25 | - Squash-merge PRs  | 
16 | 26 | - Use the following format for the squashed commit title: `<module> : <commit title> (#<issue_number>)`. For example: `utils : fix typo in utils.py (#1234)`  | 
17 | 27 | - 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  | 
20 |  | -- When merging a PR by a contributor, make sure you have a good understanding of the changes  | 
 | 28 | +- Let other maintainers, merge their own PRs  | 
 | 29 | +- When merging a PR, make sure you have a good understanding of the changes  | 
21 | 30 | - 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 | 31 | 
 
  | 
23 | 32 | # Coding guidelines  | 
 | 
117 | 126 |     #endif // FOO  | 
118 | 127 |     ```  | 
119 | 128 | 
  | 
 | 129 | +# Code maintenance  | 
 | 130 | +
  | 
 | 131 | +- Existing code should have designated collaborators and/or maintainers specified in the [CODEOWNERS](CODEOWNERS) file reponsible for:  | 
 | 132 | +  - Reviewing and merging related PRs  | 
 | 133 | +  - Fixing related bugs  | 
 | 134 | +  - Providing developer guidance/support  | 
 | 135 | +
  | 
 | 136 | +- When adding or modifying a large piece of code:  | 
 | 137 | +  - If you are a collaborator, make sure to add yourself to [CODEOWNERS](CODEOWNERS) to indicate your availability for reviewing related PRs  | 
 | 138 | +  - If you are a contributor, find an existing collaborator who is willing to review and maintain your code long-term  | 
 | 139 | +  - Provide the necessary CI workflow (and hardware) to test your changes (see [ci/README.md](https://github.com/ggml-org/llama.cpp/tree/master/ci))  | 
 | 140 | +
  | 
 | 141 | +- 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.  | 
 | 142 | +  _(NOTE: for legacy reasons, existing code is not required to follow this guideline)_  | 
 | 143 | +
  | 
120 | 144 | # Documentation  | 
121 | 145 | 
  | 
122 | 146 | - Documentation is a community effort  | 
 | 
0 commit comments