From e9b453dccc1433fa8dbd86a2d3180a4686a08b99 Mon Sep 17 00:00:00 2001 From: felix920506 Date: Thu, 25 Jun 2026 13:57:25 +0800 Subject: [PATCH 1/2] Add AI usage guidelines in contributing --- CONTRIBUTING.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c6f7ab280..d2095982d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -58,3 +58,23 @@ Some of the designs in there are already outdated or still a work in progress. W Finamp uses Weblate to manage translations: **https://hosted.weblate.org/engage/finamp/** Feel free to add new languages if yours isn't there yet. If you have any questions, such as the context of a string, you can ask in the [Translation Discussions](https://github.com/jmshrv/finamp/discussions/categories/translations). + +## Development Standards and AI / LLM Usage + +1. **Design & Intent:** You should think about the problem you are trying to solve, and what approach you would like to take, before you start coding. Clearly verify and document the problem, the approach chosen, and the justification behind the chosen path. If unsure, discuss with the team. + +2. **Verification:** After you have written the code (AI-assisted or not), you should verify the code works as expected. Screenshots and/or videos are good ways to share your test results. + +3. **Ownership & Sustainability**: You are responsible for the code you write. Adding a new feature is a long-term commitment. We view contributors as the owners of the features they introduce. We want to keep the codebase healthy, so if a feature becomes unmaintainable, we may need to deprecate or remove it. + +4. **AI usage:** + + 4-1. **Disclosure & Responsibility:** If a PR was mostly generated by AI, you should include a statement in the PR comment on which tool / model you are using, and confirm that you are responsible for the code. This statement will be recorded in the merge commit message for documentation. + + 4-2. **Attribution:** LLM co-authors should not be included in commits. Please remove them before submitting PRs. We want to ensure human contributors receive the credit. + + 4-3. **Communications:** LLMs may be used for PR descriptions or comments where appropriate. However, you should be in charge of the PR, and should not be acting as an agent of the LLM. AI output should not be blindly echoed. + +5. **Scope & Complexity:** PRs should be scoped and focused. If a PR starts getting too large or include changes across a wide area of code, we may ask you to split the PR into multiple smaller PRs. + +6. **Code Quality:** Code quality requirements are judged on a case-by-case basis during review. Poor quality, low effort PRs may be closed without further explanation at the discretion of maintainers. From 2999ba08608c3336e5826c9ad5a2db942781a1e2 Mon Sep 17 00:00:00 2001 From: felix920506 Date: Wed, 15 Jul 2026 18:00:55 +0800 Subject: [PATCH 2/2] Change wording and style to better match the rest of the document and be less harsh --- CONTRIBUTING.md | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index d2095982d..91e187949 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -61,20 +61,16 @@ Feel free to add new languages if yours isn't there yet. If you have any questio ## Development Standards and AI / LLM Usage -1. **Design & Intent:** You should think about the problem you are trying to solve, and what approach you would like to take, before you start coding. Clearly verify and document the problem, the approach chosen, and the justification behind the chosen path. If unsure, discuss with the team. +Here are some guidelines that will help you work with our maintainers and contributors. Please read them before contributing. -2. **Verification:** After you have written the code (AI-assisted or not), you should verify the code works as expected. Screenshots and/or videos are good ways to share your test results. +Think about the problem you are trying to solve, and document it before starting work. We like to see why you are making a change, not just the change itself. If you are unsure, please join our Discord server and discuss with other contributors and maintainers. -3. **Ownership & Sustainability**: You are responsible for the code you write. Adding a new feature is a long-term commitment. We view contributors as the owners of the features they introduce. We want to keep the codebase healthy, so if a feature becomes unmaintainable, we may need to deprecate or remove it. +After you have written the code, test it to make sure everything is working as expected. We like to see screenshots and/or videos of your work, especially when it is related to the UI/UX or playback functions. -4. **AI usage:** +We want to keep the codebase healthy, maintainable and focused, therefore we may be picky about what features we choose to take on. Please understand that we have limited resources, and please discuss with maintainers before starting your implementation. - 4-1. **Disclosure & Responsibility:** If a PR was mostly generated by AI, you should include a statement in the PR comment on which tool / model you are using, and confirm that you are responsible for the code. This statement will be recorded in the merge commit message for documentation. +AI usage is expected to be clearly disclosed, including what tool and what model is used. You should however not include Co-authored by tags. We want to ensure human contributors receive the credits. You should also think through what you are being fed by AI tools, and not blindly echo their output. - 4-2. **Attribution:** LLM co-authors should not be included in commits. Please remove them before submitting PRs. We want to ensure human contributors receive the credit. +We want PRs to be scoped and focused. If a PR starts getting too large, we may ask you to split the PR into multiple smaller ones. - 4-3. **Communications:** LLMs may be used for PR descriptions or comments where appropriate. However, you should be in charge of the PR, and should not be acting as an agent of the LLM. AI output should not be blindly echoed. - -5. **Scope & Complexity:** PRs should be scoped and focused. If a PR starts getting too large or include changes across a wide area of code, we may ask you to split the PR into multiple smaller PRs. - -6. **Code Quality:** Code quality requirements are judged on a case-by-case basis during review. Poor quality, low effort PRs may be closed without further explanation at the discretion of maintainers. +Code quality will be judged manually on a case-by-case basis during review. You should strive to produce high quality code.