Add guidelines for using AI tools #771
Conversation
|
Thanks @chriscool this looks good, some small nits from me. Feel free to ignore! :) |
| code or documentation in general. Now, if it's only a few lines to fix | ||
| a bug or to implement a common pattern or summarize something, and if | ||
| that looks specific enough to a current concrete problem a developer | ||
| is working on that might be OK. |
There was a problem hiding this comment.
I would drop this, mostly because we clearly state that we're unsure of how the legality works out. Perhaps we can add something like:
Only use such tools at your own discretion.
There was a problem hiding this comment.
I think it's a general rule about copyrighted work that if there are only a few ways, or a common way, to do something, then those cannot be copyrighted (see https://en.wikipedia.org/wiki/Sc%C3%A8nes_%C3%A0_faire).
I don't want to put that Wikipedia link in the doc, as I don't think it's worth distracting people with this.
| They can also use AIs to help with debugging, or with checking for | ||
| obvious mistakes, things that can be improved, things that don't match | ||
| our style, guidelines or our feedback, before sending it to us. | ||
|
|
There was a problem hiding this comment.
Should we also add a point, that applications which are AI generated and not following our guidelines, are very like to be dropped?
There was a problem hiding this comment.
Yeah, right, I have just force pushed a new commit that adds the following:
For another, unfortunately common, example, it's unacceptable to send
us an application that has obviously been AI generated and doesn't
follow our guidelines or the feedback we previously gave to other
applicants. Those applications will be dropped.
chriscool
force-pushed
the
ai-guidelines
branch
from
2ee0ce1 to
3ce8bee
Compare
General-Application-Information.md
Outdated
| It's unacceptable to send us something that is obvious AI slop, or | ||
| that sounds overly formal or bloated, or that looks good on the | ||
| surface but makes no sense, or that senders don’t understand or cannot | ||
| explain. It just wastes our time and we cannot accept it. | ||
|
|
There was a problem hiding this comment.
Someone has sent a lot of AI-generated patches to the mailing list and even to my personal email without sending to the mailing list.
Should we also mention that we don't allow this for microproject explicitly. And also should we add a rule if the students violate the rule, we won't consider them.
There was a problem hiding this comment.
@shejialuo, yeah right, that might help too. I have added the following:
In general, it's unacceptable to send AI-generated patches or messages
as-is to the mailing list or to mentors' or developers' personnal
email addresses. We won't consider candidates doing that.
I have also added a section called "Blindly using AI is far worse than not applying" and tried to improve other things in the new version I just sent.
Thanks!
chriscool
force-pushed
the
ai-guidelines
branch
from
3ce8bee to
4fc1a6a
Compare
There have been discussions both between Git GSoC mentors among themselves and between all the GSoC mentors on the Google Summer of Code Mentors List (
[email protected]) about applicants using AI more and more. It seems related to a big increase in the number of spam proposals that Git and some other project have been receiving recently.Let's try to address this issue by providing guidelines for using AI tools to mentoring program candidates.
The Conservancy also recently organized talks about the use of AI tools to develop open source software. I have tried to take this into account especially by adding a "Legal issues" section in the guidelines.