> > In particular, you must not use AI-generated text in a direct conversation > > with a human reviewer. > > I think this is too restrictive. A contributor may easily reach the limits of > their understanding during a code review, and I think it's ok to resort to > using an LLM then. I think it's fair to require that they clearly mark the > LLM-generated part of their response though.
It doesn't sound like the requirement would be for a reviewer or contributor not to consult an LLM to help them understand something they previously didn't; only that the written reply, after understanding, come from them. In other words, a contributor would need to understand whatever they're asking another person to read, whether text or code. > > P2: Full responsibility > > > You must understand, and be able to explain, every line of code, and every > > sentence of documentation. Every line! > > I think that's a good goal, but even for MRs, maybe too strict a requirement. > Where do you draw the line? Is the contributor expected to understand every > (pre-existing) function they used? To what extent? Strictness and performance > characteristics too? I'd hope that contributors wouldn't use any function -- pre-existing or not -- that they didn't have an understanding of, including relevant performance characteristics. > [...] LLMs are already very capable at debugging. How about investing in > fuzzing or better automated testing, so bugs are discovered before they make > it into a release? As I read it, there's no prohibition on doing any of these things! A person would be welcome to use an LLM to fuzz or do automated testing, but then they'd need to verify themselves that the bug is real, and explain it, rather than putting that verification work onto others. They'd also be free to use an LLM to understand the bug(s) they discovered. --- For what it's worth, from the peanut gallery of people who've only contributed to GHC in relatively small ways, I was quite pleased to read SPJ's nuanced proposal and found its suggestions very reasonable and forward-thinking. It reminded me about the excitement of working with other (real) people on a project as wonderful as GHC. - Tom _______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
