[Discussion] Include AI usage section in contributing guidelines

[RitikaPahwa4444]

We had a thread in the GSoC mentors list this year that suggested several reasons to add a section on AI usage in the community guidelines, given that vibe coding is on the rise these days. We did not participate in GSoC this year, so probably did not notice much of a difference.

However, sometimes I felt that certain PRs were not given much thought by a few contributors, due to which I am starting this discussion thread. Since our reviewers are volunteers, contributions requiring several iterations of review would not be a good use of their time if the changes are significantly deviating from what is actually required to fix the issue. We shouldn't be against the use of AI as long as the contributor understands the intent behind the changes.

PS: The number of such PRs is still minimal, thanks to our wonderful community ❤️

[nicolas-raoul]

We shouldn't be against the use of AI as long as the contributor understands the intent behind the changes.

I totally agree.

As a person who reviews a lot of pull requests for various projects, I suspect non-understood AI use when:

• The pull request is unnecessarily long.
• There are a lot of unrelated changes.
• Sometimes it does not fix the issue.
• When I request a change, other changes appear too, so I need to ask for changes more times than usual. It feels a bit like what happens when I use a AI tool like Cursor and it starts modifying random things because it does not know how to solve the issue.

So I would give this advice:

• Before sending a pull request, make sure each change is really needed. Actually try undoing each change, and keep only the changes without which the issue is not fixed.
• Make sure you really understand what each change is doing. If you call a new method, read the documentation of that method to be sure it does what you want.
• In the pull request's description, post two screencasts: one screencast showing the behavior before (demonstrating the bug), and one screencast showing the new behavior for the same operation (demonstrating the fix). If not easy to demonstrate in the UI, pastes of filterde logcat is OK.