Monorepo for Tangled tangled.org

AI Contribution Guidelines #394

Open opened by alexia.starlightnet.work

From what I could tell, Tangled currently lacks guidelines outlining whether or not Pulls assisted or created by Generative AI are accepted, and if so, to what extent.

It would be beneficial if this information could be added to the Contribution Guidelines or to a separate file on the matter.

Our position is that we hold all external pull requests to the same standard of review, whether they are AI-assisted or not. Ultimately, the patch owner is responsible for understanding and defending the code they submit, regardless of how it was produced.

We don’t currently distinguish between AI-generated and non-AI-generated contributions, but perhaps adding a short note to the contribution guidelines to clarify this expectation makes sense.

Perhaps something like:

Tangled does not differentiate between AI-assisted and non-AI-assisted contributions. All pull requests are reviewed under the same standards. Contributors are expected to fully understand and be able to justify the code they submit, regardless of how it was authored.

Our position is that we hold all external pull requests to the same standard of review

fwiw 100% support this stance (as as oss maintainer who is routinely frustrated by ai slop PRs). "AI-assisted" is already quite hazy as a binary characteristic for a diff. as LLMs are more fully integrated into dev cycles, it seems it'd be complex / mostly irrelevant for contributors to describe the sources of LLM influence on the eventual diff

also for the data point, we tried this for a bit and the most inconsiderate offenders failed to self-report their AI use

I don't think the exact tool must be disclosed

this is why i suggested that “AI-assisted” was hazy as a binary characteristic. if you google something and ai mode shows up, is it ai assisted? where is the line?

You can take a note from how other projects handle this. Bevy Engine has a taken a position of no AI contributions for various reasons: https://bevy.org/learn/contribute/policies/ai/

For things like issues, using AI to help write an issue in English because it is not a language you are comfortable with is fine, but not when using to create issues wholesale without testing the bug yourself. Nor for contributions to avoid problems of overwhelming maintainers and to avoid problems with code attribution/licensing issues.

Bevy has had a fair number of slop issues and PRs thrown at them, so they decided to nip that in the bud by explicitly saying no to AI generated contributions. There's still wiggle room to use AI when contributing, but the onus is on the author to do due diligence and also not to submit work that hasn't been modified or iterated on by human hands (to avoid the licensing issues described).

Personally, I'd make it clear that AI generated code is less likely to be accepted for a lot of the same reasons as Bevy have outlined. In the end of the day, liability is a thing, and as an OSS project, you don't want to open yourself up to more liability than you can handle.

When it comes to accepting or not accepting AI contributions in general, the matter seems pretty straightforward at this point.

If a project accepts them, then they have to deal with the extra work this will create when it's used poorly.

If a project doesn't accept them, then they have to deal with the extra work when they're used poorly anyway (though maybe somewhat less due to honest participants). Furthermore, the project that doesn't accept them is going to have regular arguments about what's AI assisted or not and community members will spend much of their energy pointing fingers at each other.

This would seem to be an uneven contest except there are also lots of people who actively enjoy arguing about AI and pointing fingers, and a "not accepted" policy on a project gives them plenty of opportunities to entertain that vocation.

Just my 2c - I'm only a minor contributor and will happily respect whatever the team decides.

That sounds like a fair old burden on the maintainers but if they're feeling up for it, more power to them.

I'll take your last paragraph as hyperbole... I assume we agree that guidelines around commit message formatting, or that there must not be any linter errors, or that the code must be organised into the correct locations are all effective and enforceable guidelines. If you want to write a guideline around something that cannot be determined by looking at the diff, then my commentary above applies.

Sign up or Sign in to add to the discussion.