yes, thanks for the very reasonable proposal. I'am +1 fully agree With best wishes, Alex Lozoviyuk CoinIndex.agency, CTO/founder https://coinindex.agency https://contractmarketcap.com
E-mail: [email protected] | Telegram: @aleks_raiden LinkedIn: https://www.linkedin.com/in/aleksraiden Facebook: https://www.facebook.com/aleksandr.lozovyuk Twitter: https://twitter.com/abrdev Github: https://github.com/aleksraiden ср, 3 дек. 2025 г. в 16:14, Edward Xu <[email protected]>: > > Hi Twice, > > Thanks very much for your proposal and effort. It's thoughtful, > comprehensive and would help us build a better community. > > I'm +1 fully support on this proposal. > > Best Regards, > > Edward Xu > > On 12/1/2025 3:05 PM, hulk wrote: > > Thank you for putting together such a thoughtful and timely proposal. > > I fully support establishing clear, pragmatic guidelines for > > AI-assisted contributions to Kvrocks. > > > > Your proposal hits the right balance: it encourages the productive use > > of modern tools > > while protecting the project’s review capacity, code quality, and > > legal compliance. > > > > I’m +1 on moving forward with this proposal. > > > > On Mon, 1 Dec 2025 at 14:50, Twice <[email protected]> wrote: > >> Hi all, > >> > >> LLM-based “vibe coding” is becoming more common, and we are already > >> seeing AI-assisted patches in the wild. To keep the project healthy > >> while still benefiting from these tools, I’d like to propose a > >> lightweight guideline for AI-assisted contributions to Kvrocks. > >> > >> ________________________________ > >> > >> Goals > >> > >> Protect reviewer bandwidth > >> Kvrocks is a small community with limited review capacity. We want to > >> avoid being flooded by low-quality or hard-to-review AI-generated PRs. > >> > >> Use AI as a benefit, not a burden > >> We should be able to use LLMs to speed up development and improve > >> quality, while avoiding the confusion, noise and legal risks they can > >> introduce. > >> > >> Stay aligned with ASF policy > >> All AI-generated content must comply with the ASF Generative Tooling > >> Guidance and ASF licensing policies. > >> > >> ________________________________ > >> > >> What is not allowed > >> > >> Fully LLM-generated PRs that the author does not understand are not > >> acceptable. > >> > >> Typical signs of such PRs: > >> > >> The author cannot explain what the change does or why it is correct. > >> > >> The author cannot discuss the impact on Kvrocks’ behavior. > >> > >> The patch ignores existing project conventions or design choices, and > >> the author cannot justify them. > >> > >> In these cases, it is usually better to: > >> > >> Open a high-quality issue describing the problem, expected behavior, > >> and context. > >> > >> Discuss possible solutions with the community before attempting a patch. > >> > >> ________________________________ > >> > >> What is allowed (and encouraged) > >> > >> Using AI tools as an assistant is welcome, as long as: > >> > >> The human author remains responsible > >> > >> You understand the change you are submitting. > >> > >> You are able to answer reviewers’ questions. > >> > >> You are willing to revise or rewrite AI-generated parts during review. > >> > >> You understand the relevant code > >> > >> You have read the “How to Contribute” documentation. > >> > >> You have at least a basic understanding of the parts of the codebase > >> you are touching. > >> > >> You are transparent about AI usage > >> > >> In the PR description, briefly mention if AI tools were used and for > >> what (e.g. tests, docs, initial draft of implementation). > >> > >> If there are small pieces of code that you don’t fully understand, > >> call them out explicitly and ask for help. > >> > >> Example comment in a PR: > >> > >> “Lines 120–160 in foo.cc were suggested by an LLM. I understand the > >> overall logic but I’m not 100% sure about edge cases around > >> replication. Feedback is welcome.” > >> > >> ________________________________ > >> > >> ASF Generative Tooling Guidance > >> > >> All AI-assisted content must follow ASF rules, including: > >> > >> No incompatible licensing terms introduced by the tool. > >> > >> No hidden or undisclosed third-party code. > >> > >> When in doubt, contributors should review the ASF Generative Tooling > >> Guidance and 3rd-party licensing policy, and ask the community or ASF > >> Legal through normal channels. > >> > >> We may recommend adding simple provenance markers (e.g. Generated-by: > >> <Tool> in commit messages), but this can be discussed further. > >> > >> ________________________________ > >> > >> For reviewers > >> > >> Reviewers are encouraged to: > >> > >> Ask whether AI tools were used if the patch looks heavily > >> machine-generated. > >> > >> Check that the author understands the change; if not, suggest > >> converting it into an issue or closing the PR. > >> > >> Prioritize PRs with clear problem statements, tests, and explanations > >> over opaque AI dumps. > >> > >> Flag suspected ASF policy or licensing issues for PMC / ASF Legal > >> follow-up. > >> > >> ________________________________ > >> > >> Evolution of this policy > >> > >> LLMs and ASF guidance are evolving quickly. This proposal is > >> intentionally simple and should be revisited when: > >> > >> ASF updates its Generative Tooling Guidance, or > >> > >> New tools significantly change how we write or review code. > >> > >> In the long term, if tools become strong enough (for example, to > >> reliably assist with review in a compliant way), we can relax or > >> adjust parts of this policy. > >> > >> ________________________________ > >> > >> Next steps > >> > >> I propose we: > >> > >> Discuss this on the list and refine the text if needed. > >> > >> Once there is rough consensus, add a short “AI-assisted contributions” > >> section to "How to Contribute" in the website. > >> > >> Comments and suggestions are very welcome. > >> > >> Best, > >> Twice > > > >
