mirror of
https://github.com/mostlygeek/llama-swap.git
synced 2026-09-07 16:37:22 +02:00
Recently issues and pull requests are coming in at the same time. Updating the rules to clarify what is acceptable.
29 lines
1.8 KiB
Markdown
29 lines
1.8 KiB
Markdown
# 1. Contributing
|
|
|
|
The llama-swap project considers two types of contributing roles:
|
|
|
|
1. Contributors are allowed to create issues, open pull requests and engage in discussion.
|
|
2. Maintainers have contributor privileges and are also allowed to merge pull requests. Maintainers have an obligation to maintain the quality of the project.
|
|
|
|
## 2. Issues and pull requests
|
|
|
|
1. Every pull request must reference an existing issue.
|
|
2. ALWAYS open issues or pull requests yourself.
|
|
3. ALWAYS write the descriptions yourself. You must understand your contribution well enough to be able to describe its value and the reasoning behind it.
|
|
4. NEVER have an agent create issues and pull requests.
|
|
5. NEVER create an issue because you already have a pull request just to satisfy the first rule.
|
|
6. Maintainers may close issues or pull requests that look like slop.
|
|
|
|
## 3. Guidelines for humans and agents
|
|
|
|
1. Good ideas, good designs and thoughtful requests are much more valuable contributions. Code is cheap now. The maintainers have coding agents too.
|
|
2. AI written code is acceptable. AI written issues and pull requests are not.
|
|
3. Search for existing issues or PRs before creating a new one. Adding feedback to existing discussions is preferred.
|
|
4. Contributions must benefit most users. Do not submit PRs for niche or narrow features.
|
|
5. Contributors must understand all code they submit. Perform a thorough review before submitting.
|
|
6. New contributors are limited to one open PR at a time.
|
|
7. Maintainers will squash and merge all PRs into the `main` branch.
|
|
8. Write the PR description so it can be used as the squash commit message.
|
|
9. Maintainers may ask you to squash your PR into a single commit before merging.
|
|
10. Keep PRs small and focused. Change only the code necessary to fix the referenced issue. Maintainers will reject changes that are outside the issue discussion.
|