[docs] Add AI usage guidelines #141

Copy link

Copy link

jeanbaptisteC commented 2026年02月05日 08:21:48 +01:00

Seems very to be specific to our main repository, that's doesn't make sense to be here
Same for two sentences under

Seems very to be specific to our main repository, that's doesn't make sense to be here Same for two sentences under

pastk commented 2026年02月05日 10:00:47 +01:00

DCO and PR guides (and other docs in general) apply to the whole project.

DCO and PR guides (and other docs in general) apply to the whole project.

pastk commented 2026年02月11日 05:14:02 +01:00

I've marked it as "resolved" for now as it seems this concern is not supported by many people and/or is better addressed by linking from other repos, see #141 (comment)

And actually I'd prefer to have this doc merged into the main repo, not governance

I've marked it as "resolved" for now as it seems this concern is not supported by many people and/or is better addressed by linking from other repos, see https://codeberg.org/comaps/Governance/pulls/141#issuecomment-10376678 And actually I'd prefer to have this doc merged into the main repo, not governance

jeanbaptisteC commented 2026年02月05日 08:30:10 +01:00

Also require to add wiki documentations

Also require to add wiki documentations

pastk commented 2026年02月05日 10:07:22 +01:00

it says "docs" already (and also there is "etc")

IMO we don't need to precisely enumerate all communication ways.
People do understand generalizations (esp. given that there are some examples) and can derive that wiki docs do fall under this guideline.

it says "docs" already (and also there is "etc") IMO we don't need to precisely enumerate all communication ways. People do understand generalizations (esp. given that there are some examples) and can derive that wiki docs do fall under this guideline.

pastk commented 2026年02月05日 10:27:12 +01:00

Actually I'm not sure if its worth mentioning at all as ~98% of text had been changed :)

Actually I'm not sure if its worth mentioning at all as ~98% of text had been changed :)

gedankenstuecke commented 2026年02月06日 11:47:05 +01:00

This is still a no-go for me. If we start using AI for responses to users this will immediately backfire and hurt CoMaps reputation amongst it's core user audience.

This is still a no-go for me. If we start using AI for responses to users this will immediately backfire and hurt CoMaps reputation amongst it's core user audience.

gedankenstuecke commented 2026年02月06日 11:49:14 +01:00

This seems like a clear invitation to start using AI and I don't think we should suggest this to people.

Generally this draft seems to invite people to make use of those tools, which is a very different approach not just I tone but also actual viewpoint

This seems like a clear invitation to start using AI and I don't think we should suggest this to people. Generally this draft seems to invite people to make use of those tools, which is a very different approach not just I tone but also actual viewpoint

pastk commented 2026年02月08日 08:58:49 +01:00

I've rephrased it to sound "less welcoming". PTAL 🙏

I've rephrased it to sound "less welcoming". PTAL 🙏

mnalis commented 2026年02月09日 06:30:54 +01:00

That sounds much too weak to me. "consider discussing extent of AI usage in advance"... it is not something they should "consider", it is IMHO an absolute prerequisite. In RFC2119 terms, it's a "MUST", not a "MAY".

That sounds much too weak to me. "_consider_ discussing extent of AI usage in advance"... it is not something they should "consider", it is IMHO an absolute prerequisite. In [RFC2119](https://www.rfc-editor.org/rfc/rfc2119) terms, it's a **"MUST"**, not a **"MAY"**.

pastk commented 2026年02月09日 14:12:03 +01:00

Thanks!
I'll change to Limit scope of your AI-assisted PRs or discuss your contribution idea and extent of AI usage in advance...

Thanks! I'll change to `Limit scope of your AI-assisted PRs or discuss your contribution idea and extent of AI usage in advance...`

mnalis commented 2026年02月09日 06:05:09 +01:00

Sure, they could use it, but it should be emphasized that they may only use AI in addition to all the other checks that would otherwise need doing, not instead of it. Just like e.g. we don't prohibit use of static code analyzers or fuzzying checks; but those are not a replacement for human actually checking the PR themselves.

Sure, they _could_ use it, but it should be emphasized that they may only use AI **in addition** to all the other checks that would otherwise need doing, not **instead of it**. Just like e.g. we don't prohibit use of static code analyzers or fuzzying checks; but those are not **a replacement** for human actually checking the PR themselves.

pastk commented 2026年02月09日 14:18:07 +01:00

This was my intention indeed, I'll change it to reviewers could in addition use AI to... to make it more clear.

And I'm open for better wording suggestion!

This was my intention indeed, I'll change it to `reviewers could in addition use AI to...` to make it more clear. And I'm open for better wording suggestion!

gedankenstuecke commented 2026年02月09日 15:03:14 +01:00

I think "should be tested" is too weak, similar to the earlier comment about MAY ./. MUST.

I think "should be tested" is too weak, similar to the earlier comment about MAY ./. MUST.

pastk commented 2026年02月10日 15:17:47 +01:00

I'll change to more imperative "- test the code to ensure its reasonably free from bugs and security issues"

I'll change to more imperative "- test the code to ensure its reasonably free from bugs and security issues"

mnalis commented 2026年02月09日 06:25:17 +01:00

While original #136 was somewhat too legalise, it had IMHO right intention in mind - minimize problems that AI bring but making clear that use of AI is tolerated in some more benign cases, but is generally unwanted because it is hard work even to estimate amount of problems it brings¹ . That was more aligned with my views² .

This part of PR #141 however sounds way too much like some pro-AI pamphlet on "How to increase use of AI to its absolute maximum tolerable limits, and only leave some minimum leeway to people not wanting to be overwhelmed by it", which is policy I do not subscribe to.

Project-wise, I am fine with AI being used for providing additional checks as safety net after the human has their due diligence³ , and for debugging (i.e. explaining to humans why some thing might be broken).

And I'm for allowing AI in other situations where technical debt possibility is very low -- e.g. translations, some tests or boilerplate code (but only let AI do the test if it never was involved with code, or vice versa).

I'd also accept AI in very small amount of communication - i.e. for translations but not for generating lists/walls of text. IOW it may be fine only when the person using AI is investing at least as much (and preferably significantly more⁴ ) effort as the person(s) they're expecting the answer from.

But they should IMHO definitely understand all of the AI-code they're submitting and be able to explain it (and I mean them explaining it, by learning it in advance to submission, and not copy/pasting the question to AI to explain it after the fact) -- it is not optional IMHO.

While original https://codeberg.org/comaps/Governance/pulls/136 was somewhat too legalise, it had IMHO right intention in mind - minimize problems that AI bring but making clear that use of AI is **tolerated** in some more benign cases, but is generally **unwanted** because it is hard work even to estimate amount of problems it brings[^1]. That was more aligned with my views[^4]. This part of PR #141 however sounds way too much like some pro-AI pamphlet on _**"How to increase use of AI to its absolute maximum tolerable limits, and only leave some minimum leeway to people not wanting to be overwhelmed by it"**_, which is policy I [do not subscribe to](https://codeberg.org/comaps/Governance/pulls/136/files#issuecomment-10317772). Project-wise, I am fine with AI being used for providing **additional** checks as safety net _after_ the human has their due diligence[^3], and for debugging (i.e. explaining to humans why some thing might be broken). And I'm for allowing AI in other situations where technical debt possibility is very low -- e.g. translations, some tests or boilerplate code (but only let AI do the test if it never was involved with code, or vice versa). I'd also accept AI in very small amount of communication - i.e. for translations but not for generating lists/walls of text. IOW it may be fine **only** when the person using AI is investing **at least** as much (and preferably significantly more[^2]) effort as the person(s) they're expecting the answer from. But they should IMHO **definitely** understand all of the AI-code they're submitting and be able to explain it (and I mean them explaining it, by learning it in advance to submission, and not copy/pasting the question to AI to explain it after the fact) -- it is not optional IMHO. [^1]: starting from more direct extreme inequality to scarce human resources needing to tend to it [i.e. communication human vs. AI wall-of-text], to the huge technical debt it brings unless much more review time is allocated then for code written just by humans, which make easily recognizable mistakes [^2]: otherwise, if it takes more resources to get usable contributions from AI-helped-contributors, it would be more efficient (and _significantly_ more bug-free) if no contributions were accepted at all and core maintainers wrote all the code by themselves. [^3]: as other way around is sure recipe for brain rot, as human will just allow AI to do everything and barely be able to spot anything themselves with time as their brain would degrade (i.e. _"use it or lose it"_ principe, applies to brain as much as it does for muscles or any other skill). [^4]: although I should not it also sounded too bent on _"how to make sure we regulate & enumerate all the cases & reliably catch & punish AI-users"_, instead of intentionally being slightly fuzzy and leaving more agency to the maintainers deciding when something is acceptable or not. Such attempts at overregulation or overengineering do not work well IRL IMO

pastk commented 2026年02月09日 14:31:37 +01:00

Thanks for elaborating!
But TBH I don't really understand what was your intention of the scope of this feedback?

Is it specifically about point 4. which applies only to specific cases like cherry-picking from upstreams? If there are concerns with the wording of it then I'm open to suggestions.

If its about the whole idea of AI usage extent allowed in code changes - we've had an opinion poll already #141 (comment) and the conclusion is pretty clear (and it won't change if we add your vote there).
The current doc is meant to reflect this balance of opinions, so we can continue working on better wording and details, but it should stay inline with the poll result.

Thanks for elaborating! But TBH I don't really understand what was your intention of the scope of this feedback? Is it specifically about point 4. which applies only to specific cases like cherry-picking from upstreams? If there are concerns with the wording of it then I'm open to suggestions. If its about the whole idea of AI usage extent allowed in code changes - we've had an opinion poll already https://codeberg.org/comaps/Governance/pulls/141#issuecomment-10441862 and the conclusion is pretty clear (and it won't change if we add your vote there). The current doc is meant to reflect this balance of opinions, so we can continue working on better wording and details, but it should stay inline with the poll result.

gedankenstuecke commented 2026年02月09日 15:06:47 +01:00

I don't think the point 4 about Code changes could be accepted without requiring the contributor to have deep understanding of them really reflects the poll outcome.

The poll was for "if the contributor understands the changes and ensures high quality", and there seemed to be consensus (as well as in #136) to have an exemption for cherry-picked code that has already been tested but beyond that I don't think there was a clear outcome.

I don't think the point 4 about _Code changes could be accepted without requiring the contributor to have deep understanding of them_ really reflects the poll outcome. The poll was for "if the contributor understands the changes and ensures high quality", and there seemed to be consensus (as well as in #136) to have an exemption for cherry-picked code that has already been tested but beyond that I don't think there was a clear outcome.

mnalis commented 2026年02月09日 21:00:56 +01:00

@pastk wrote in #141/files (comment):

But TBH I don't really understand what was your intention of the scope of this feedback?
Is it specifically about point 4. [...] ?

No, it was generally about most¹ of "### Pull requests" section, up to and including point 4. (but Codeberg did not seem to allow me to select the scope, just single line)

The poll was for "if the contributor understands the changes and ensures high quality"

And I would agree with that most popular vote, so it wouldn't change. Key words in that vote being "if" (i.e. meaning the conditions MUST be satisfied, IOW they are not merely optional or recommended) and "and" (meaning both conditions must be true, i.e. neither is optional).

The current doc is meant to reflect this balance of opinions, so we can continue working on better wording and details, but it should stay inline with the poll result.

Agreed. To clarify, my opinion was that text of PR strays from the poll result as I understand it, i.e. this PR seems to make too many things only "optional" / "recommended", instead of MUST (which is how I interpret what the poll said).

@pastk wrote in https://codeberg.org/comaps/Governance/pulls/141/files#issuecomment-10469510: > But TBH I don't really understand what was your intention of the scope of this feedback? > Is it specifically about point 4. [...] ? No, it was generally about most[^1] of "### Pull requests" section, up to and including point 4. (but Codeberg did not seem to allow me to select the scope, just single line) > The poll was for "**if** the contributor understands the changes **and** ensures high quality" And I would agree with that most popular vote, so it wouldn't change. Key words in that vote being **"if"** (i.e. meaning the conditions **MUST** be satisfied, IOW they are not merely _optional_ or _recommended_) and **"and"** (meaning **both** conditions must be true, i.e. neither is optional). > The current doc is meant to reflect this balance of opinions, so we can continue working on better wording and details, but it should stay inline with the poll result. Agreed. To clarify, my opinion was that text of PR strays from the poll result as I understand it, i.e. this PR seems to make too many things only "optional" / "recommended", instead of **MUST** (which is how I interpret what the poll said). [^1]: but not all; e.g. point `1.` was fine.

pastk commented 2026年02月10日 12:27:36 +01:00

@mnalis sorry there is some context lost - I've formulated the poll option simply as "allowed if the contributor understands the changes and ensures high quality" because its too little space to elaborate on what is "high quality", so I've posted details on what I mean by that immediately after the poll (see the screenshot)

And the second important contextual thing is that it was my intention to propose a different draft which would have a "guidelines" feel (like our other contribution docs) in contrast to a set of strict "musts" (which I think is not suitable for a community project based on volunteers - there could be some "musts" indeed when necessitated by e.g. legal requirements - but otherwise my vision of community assumes ability of people to be reasonable and have common sense and act in a good faith instead of unnecessarily forcing each other to act in a certain way by referring to "musts").

@mnalis sorry there is some context lost - I've formulated the poll option simply as "allowed if the contributor understands the changes and ensures high quality" because its too little space to elaborate on what is "high quality", so I've posted details on what I mean by that immediately after the poll (see the screenshot) And the second important contextual thing is that it was my intention to propose a different draft which would have a "guidelines" feel (like our other contribution docs) in contrast to a set of strict "musts" (which I think is not suitable for a community project based on volunteers - there could be some "musts" indeed when necessitated by e.g. legal requirements - but otherwise my vision of community assumes ability of people to be reasonable and have common sense and act in a good faith instead of unnecessarily forcing each other to act in a certain way by referring to "musts").

pastk commented 2026年02月10日 12:40:31 +01:00

@gedankenstuecke re point 4 specifically.

My intention for the poll was that each next option embraces a previous one and allows even more things in addition to it.
All three polls are structured like this.
So in my understanding people who have voted for the "allowed if contributor understands..." also agree with "allowed for special cases like cherry-picking". I agree it wasn't 100% clear though and some people might have understood it differently.
But still you're explicit that cherry-picking is exempt despite how people might interpret the poll.

Then I don't really understand your point, maybe our ideas of what this exemption mean are different. Could you please elaborate?

(and actually I think that my cherry-picking clause is more strict than yours - mine lifts only the requirement to deeply understand while other quality guidelines stay, whereas in your draft cherry-picking is completely exempt from the agreement)

@gedankenstuecke re point 4 specifically. My intention for the poll was that each next option embraces a previous one and allows even more things in addition to it. All three polls are structured like this. So in my understanding people who have voted for the "allowed if contributor understands..." also agree with "allowed for special cases like cherry-picking". I agree it wasn't 100% clear though and some people might have understood it differently. But still you're explicit that cherry-picking is exempt despite how people might interpret the poll. Then I don't really understand your point, maybe our ideas of what this exemption mean are different. Could you please elaborate? (and actually I think that my cherry-picking clause is more strict than yours - mine lifts only the requirement to deeply understand while other quality guidelines stay, whereas in your draft cherry-picking is completely exempt from the agreement)

gedankenstuecke commented 2026年02月10日 13:49:34 +01:00

I mean it currently says "Code changes could be accepted without requiring the contributor to have deep understanding of them" ... "for small fixes which are well-tested and limited in scope (similar to human-made trial-and-error fixes)", which I'm not sure was part of the poll? 🙂

I mean it currently says "Code changes could be accepted without requiring the contributor to have deep understanding of them" ... "for small fixes which are well-tested and limited in scope (similar to human-made trial-and-error fixes)", which I'm not sure was part of the poll? 🙂

pastk commented 2026年02月10日 15:25:04 +01:00

the poll says "allowed for special cases like cherry-picking"

this special case comes from #136 (comment) and IMO makes sense

though it also looks too niche/specific to be mentioned explicitly, perhaps its fine just to have a more general "Reasonable exceptions" clause..

so if more people think its better to remove it then I'll remove it

the poll says "allowed for special cases like cherry-picking" this special case comes from https://codeberg.org/comaps/Governance/pulls/136#issuecomment-10310810 and IMO makes sense though it also looks too niche/specific to be mentioned explicitly, perhaps its fine just to have a more general "Reasonable exceptions" clause.. so if more people think its better to remove it then I'll remove it

mnalis commented 2026年02月12日 02:49:57 +01:00

@pastk wrote in #141 (comment):

And the second important contextual thing is that it was my intention to propose a different draft which would have a "guidelines" feel (like our other contribution docs) in contrast to a set of strict "musts" (which I think is not suitable for a community project based on volunteers - there could be some "musts" indeed when necessitated by e.g. legal requirements - but otherwise

Perhaps that is cultural difference, but I very much always prefer clarity. I.e. if you must do something, then the wording should reflect that without possibility of misunderstanding. So I like RFCs. They're clear. ¹

I could never get a hang of american-like² phrases like "We would be very much obliged it you could perhaps make it here somewhere around say 18:30, if that would be fine with you - we do not wish to impose" when the actual meaning is "If you don't drag your ass here by the 18:30 at the very latest, you're fired". 😅

I think the purpose of language (human or otherwise) is to transfer meaning as clearly as possible. Now, if we can make it very clear what is meant by the policy without any possibility of misunderstanding while skipping using the word "must", then it is fine, even preferable (it would sound less "aggressive").

But if we use word "could" when we actually mean "must", then it will create tension as both sides would think it means something different, and each side will cry "foul! betrayal!" - which to me is much bigger problem than occasional new contributor thinking "oh those guys dislike AI to the point I'd actually have to do some work myself, and I can't be bothered, so I better find other project to offload output of my unchecked AI prompts to" 🤷‍♂️

my vision of community assumes ability of people to be reasonable and have common sense and act in a good faith instead of unnecessarily forcing each other to act in a certain way by referring to "musts").

Well, then what is the point of having a policy at all? IMHO, the whole point of policy is to say "this is OK" and "This is NOT acceptable". Is this document even supposed to be a policy (which is how I understood its purpose)?

If we don't want to do that (which might be reasonable, i.e. we're aiming with just a soft recommendation a la BCP, but it is totally fine if people choose to ignore parts or whole of it), we might as well skip having it at all, and continue assuming people will be reasonable and have common sense and not try to contribute via AI slop. In my opinion, nobody who is "reasonable" and have "common sense" would do that, but apparently a lots of people are doing it.

Or just add a line to general PR guidelines saying "Please don't contribute slop, AI-generated or otherwise, in code or in words, and be considerate of the time of other human contributors at least as much as you are of your own time", and skip creating separate AI_USAGE.md, and call it a day?

@pastk wrote in https://codeberg.org/comaps/Governance/pulls/141#issuecomment-10494168: > And the second important contextual thing is that it was my intention to propose a different draft which would have a "guidelines" feel (like our other contribution docs) in contrast to a set of strict "musts" (which I think is not suitable for a community project based on volunteers - there could be some "musts" indeed when necessitated by e.g. legal requirements - but otherwise Perhaps that is cultural difference, but I very much always **prefer clarity**. I.e. if you **must** do something, then the wording should reflect that **_without_** possibility of misunderstanding. So I like RFCs. They're clear. [^1] I could never get a hang of american-like[^2] phrases like _"We would be very much obliged it you could perhaps make it here somewhere around say 18:30, if that would be fine with you - we do not wish to impose"_ when the _actual_ meaning is _"If you don't drag your ass here by the 18:30 at the very latest, you're fired"_. 😅 I think the purpose of language (human or otherwise) is to transfer meaning as clearly as possible. Now, if we can make it very clear what is meant by the policy _**without any possibility of misunderstanding**_ while skipping using the word **"must"**, then it is fine, even preferable (it would sound less _"aggressive"_). But if we use word "could" when we actually _mean_ "must", then it will create tension as both sides would think it means something different, and each side will cry _"foul! betrayal!"_ - which to me is much bigger problem than occasional new contributor thinking _"oh those guys dislike AI to the point I'd actually have to do some work myself, and I can't be bothered, so I better find other project to offload output of my unchecked AI prompts to"_ 🤷‍♂️ > my vision of community assumes ability of people to be reasonable and have common sense and act in a good faith instead of unnecessarily forcing each other to act in a certain way by referring to "musts"). Well, then what is the point of having a policy at all? IMHO, the whole point of policy is to say "this is OK" and "This is NOT acceptable". Is this document even supposed to be a policy (which is how I understood its purpose)? If we don't want to do that (which might be reasonable, i.e. we're aiming with just a soft recommendation a la [BCP](https://en.wikipedia.org/wiki/Best_current_practice), but it is totally fine if people choose to ignore parts or whole of it), we might as well skip having it at all, and continue assuming _people will be reasonable and have common sense_ and not try to contribute via AI slop. In my opinion, nobody who is "reasonable" and have "common sense" would do that, but apparently a lots of people _are_ doing it. Or just add a line to general PR guidelines saying _**"Please don't contribute slop, AI-generated or otherwise, in code or in words, and be considerate of the time of other human contributors at least as much as you are of your own time"**_, and skip creating separate `AI_USAGE.md`, and call it a day? [^1]: which is also probably a reason why my posts might sound "harsher" then intended - I just try to use clear wording, without sugar-coating it, as sugar-coating adds ambiguity with I consider harmful. Rest assured it is not for trying to come out as rude, but just trying to be clear 🤷‍♂️ Which is also why I sometimes restate the same thing in different words - it's adding redundancy to avoid misinterpretation. [^2]: just using German vs. American stereotypes for the contrast to explain the point, not trying to imply that all Americans or all Germans are like that! And slightly exaggerated probably (but only slightly)

pastk commented 2026年02月12日 07:34:00 +01:00

@mnalis wrote in #141 (comment):

Well, then what is the point of having a policy at all? IMHO, the whole point of policy is to say "this is OK" and "This is NOT acceptable". Is this document even supposed to be a policy (which is how I understood its purpose)?

This is not a policy, its guidelines (just like our other contribution docs). See the original post in this PR.

If you prefer a more strict approach then no problem, just vote for #136 and not for this one! :)

@mnalis wrote in #141 (comment):

But if we use word "could" when we actually mean "must"

I don't think "could" is ever used in such a context in this doc.
I've replaced some "should"s already with more assertive wording.

@mnalis wrote in https://codeberg.org/comaps/Governance/pulls/141#issuecomment-10532348: > Well, then what is the point of having a policy at all? IMHO, the whole point of policy is to say "this is OK" and "This is NOT acceptable". Is this document even supposed to be a policy (which is how I understood its purpose)? This is not a policy, its guidelines (just like our other contribution docs). See the original post in this PR. If you prefer a more strict approach then no problem, just vote for #136 and not for this one! :) @mnalis wrote in https://codeberg.org/comaps/Governance/pulls/141#issuecomment-10532348: > But if we use word "could" when we actually _mean_ "must" I don't think "could" is ever used in such a context in this doc. I've replaced some "should"s already with more assertive wording.

pastk commented 2026年02月16日 11:44:59 +01:00

@gedankenstuecke @x7z4w Finally I've removed the "small fixes similar to human-made trial-and-error fixes" explicit exception for the sake of simplicity, IMO its fine to have it implicit under "Reasonable exceptions could be made..."

@gedankenstuecke @x7z4w Finally I've removed the "small fixes similar to human-made trial-and-error fixes" explicit exception for the sake of simplicity, IMO its fine to have it implicit under "Reasonable exceptions could be made..."

gedankenstuecke commented 2026年02月09日 14:54:18 +01:00

Why "other" contributors?

Also I still do think it would be better to not just keep a vague framing of "AI" that means everything and nothing, but be specific about the kind of tools we mean. E.g. static code analysers that use specific ML (e.g. the example that @mnalis mentions) is very different from "general purpose LLMs"

Why "other" contributors? Also I still do think it would be better to not just keep a vague framing of "AI" that means everything and nothing, but be specific about the kind of tools we mean. E.g. static code analysers that use specific ML (e.g. the example that @mnalis mentions) is very different from "general purpose LLMs"

pastk commented 2026年02月10日 15:25:54 +01:00

Indeed, I'll remove "other", thanks!

Indeed, I'll remove "other", thanks!

pastk commented 2026年02月10日 15:33:26 +01:00

IMO addition of this LLMs vs non-LLMs distinction will change nothing in how the doc applies to code changes. PRs should follow guidelines of understanding, testing, following conventions, etc. regardless whether only an ML-based static code analyser or code completion has been used or a general LLM. Thus I think this distinction is not needed.

IMO addition of this LLMs vs non-LLMs distinction will change nothing in how the doc applies to code changes. PRs should follow guidelines of understanding, testing, following conventions, etc. regardless whether only an ML-based static code analyser or code completion has been used or a general LLM. Thus I think this distinction is not needed.

gedankenstuecke commented 2026年02月09日 15:08:03 +01:00

Again to weak I think, as it leaves it open to not have humans do any review, e.g. "have to be reviewed" would be better

Again to weak I think, as it leaves it open to not have humans do any review, e.g. "have to be reviewed" would be better

mnalis commented 2026年02月09日 20:42:28 +01:00

or "PRs must always be reviewed by humans who follow [...]" ?

or _"PRs must always be reviewed by humans who follow [...]"_ ?

pastk commented 2026年02月10日 15:35:04 +01:00

Thanks, changed to "have to"!

Thanks, changed to "have to"!

mnalis commented 2026年02月19日 15:09:47 +01:00

I'd try to emphasize that it AI may not be used as replacement for human review here. As currently stated, it is IMHO ambiguous/weak, even it does say "in addition", that can be misconstrued to mean "additionally, AI may be used to..." which would allow replacement of human checks, and not "extra AI checks after human has done all the reviewing work they would regularly do even if they weren't using AI" which it is intended (I hope) to convey

So perhaps something like:
"- reviewers may use AI to facilitate analysing of code changes and detecting typical problems, but only in addition to all the regular human review activities, and not as a replacement of them"

Other then that, it looks good to me...

I'd try to emphasize that it AI may not be used as replacement for human review here. As currently stated, it is IMHO ambiguous/weak, even it does say _"in addition"_, that can be misconstrued to mean _"additionally, AI may be used to..."_ which would allow replacement of human checks, and not _"extra AI checks after human has done all the reviewing work they would regularly do even if they weren't using AI"_ which it is intended (I hope) to convey So perhaps something like: "- reviewers may use AI to facilitate analysing of code changes and detecting typical problems, but only in addition to all the regular human review activities, and not as a replacement of them" Other then that, it looks good to me...

mnalis commented 2026年02月19日 15:12:05 +01:00

uh, this was supposed to apply to "5. [...] - reviewers could in addition use AI to facilitate analysing of code changes and detecting typical problems ", dunno why Codeberg it moved here (maybe I misclicked)

uh, this was supposed to apply to "5. [...] - reviewers could in addition use AI to facilitate analysing of code changes and detecting typical problems ", dunno why Codeberg it moved here (maybe I misclicked)

pastk commented 2026年02月20日 05:17:46 +01:00

Thanks! I've made it a bit shorter though

• reviewers may use AI to facilitate analysing of code changes and detecting typical problems, but only in addition to a regular human review

Thanks! I've made it a bit shorter though > - reviewers may use AI to facilitate analysing of code changes and detecting typical problems, but only in addition to a regular human review