AI-generated descriptions in issues and PRs #7377

I looked at a few approaches. Team NewPipe prohibits using generative AI to fill issue or PR templates, while FastAPI permits AI assistance for reports but requires human verification and disclosure. Apache guidance likewise keeps responsibility for generated material with the contributor. More generally, GitHub recommends descriptions that let reviewers understand a change quickly.

A balanced practice for Texera could be: require a short, human-edited summary first (problem/motivation, proposed change, and how it was verified, I believe we have a template like this for pull requests); put optional implementation detail below; disclose substantial AI assistance; and require the author to understand the submission and answer questions about it. The same compact template could apply whether or not AI was used, since verbosity rather than the tool itself is the immediate readability problem.

Alternatively we can also look at CodeRabbit. I believe they have a feature specifically aimed at AI slop, but I wouldn't trust any for profit company in terms of sustainable long term future. We'd also have to check if Apache permits this.
image

I've started to see this too in AsterixDB and I don't really care much for it either. In code it's easy to mark what was generated or not. In a discussion or other forum where it's supposed to be humans talking to humans, I think it leaves a bad impression on the reader if the text is obviously not written by a human and isn't clearly marked as such.
I like Suryaa's idea of at least enforcing that an abstract be written if it is a long issue. This way you can be certain the author actually read the generated output and didn't pass the buck onto you to determine whether or not it even makes sense.

@sshiv012 @parshimers Thanks for the input. I like the idea of requiring the author to write a brief summary at the beginning of the description.

Let's wait for other members to chime in.

I also like the idea of summary.

Here's my opinion. Issues are meant to be more abstract, describing a problem or suggesting a fix, so I don't think exact implementation details belong there. Human readability matters more, and diagrams or pictures can add a lot. Some technical detail is fine for developers who can read and follow it, but there's such a thing as being so verbose that only agents can get through it.

PRs are more technical by nature since the code changes are right there. But if the description is too verbose, reading it is basically the same as reading the source, which defeats the point of having a description at all. I agree the right balance is a section at the top written for humans, and optionally a longer technical explanation below that's mainly for agents.

If the real problem is agents writing descriptions that are too verbose and hard to read, we can require the poster to review the agent's output before publishing. The goal would be to improve human readability and cut down on wordiness, instead of assuming the generated content is good enough to post as-is.

The PR descriptions used to be simple until a certain point, when everyone started writing much more.
I don't think the problem is AI-generated descriptions. AI can also generate simple and clear descriptions.

Since @Yicong-Huang designed the current PR template, can you provide what you expect in each section?

While we welcome AI-assisted contributions, agents do tend to produce overly verbose issues, pull request descriptions, and comments. Here are my thinkings from a few perspectives:

• From a project-management perspective: A general hard limit on the length of descriptions or comments would not be ideal. These interfaces are used by both agents and humans, and humans sometimes have legitimate reasons to provide longer explanations.

• For agents: Contributors should instruct their agents to write concisely. We can reinforce this in two ways:

  1. State our expectations more firmly in AGENTS.md.
  2. Build and use agent tooling with built-in safeguards. I created a Texera/
     texera-agent-plugins (currently in a private repository) with open-issue and open-pr skills that include a verbosity gate to prevent unnecessarily long content. I am testing it with several recent issues:
     • Cache the license-eye build in the Check License Headers job #7136 ,
     • Document PR title conventions for feat vs fix, tests, dependency bumps, and backports #7393 ,
     • Remove two orphaned GUI config flags that no longer have consumers #7135
       and PRs:
     • chore(config): remove two orphaned GUI config flags with no consumers #7137
     • docs: define how to pick a PR title's type and scope #7427
     • ci: route merge-queue builds to self-hosted runner tiers with hosted fallback #7172

Please let me know what you think. The same verbosity gate will also apply to AI-assisted PR reviews performed using the Texera agent plugin.

• For humans: Although we should not impose strict length limits, encouraging concise writing would improve communication. We could add guidance to CONTRIBUTING.md recommending that issues, pull requests, and comments remain focused. Related guidance could discourage including unnecessary implementation details in issue descriptions. These should remain recommendations rather than hard requirements, which would also be difficult to enforce technically.

• For reviewers: When a description or comment is excessively long, reviewers should feel comfortable asking the author to revise it for clarity and conciseness.

AI makes it easy to generate more PRs and issues, but that also means there’s more for humans to review and understand.

The interesting part is keeping the useful context without turning every PR into a wall of AI generated text.

We’re working on a related problem around giving agents better production context, so it’s interesting to see how people are approaching this on the development side too. The short human summary + optional agent detail approach makes a lot of sense.