I'm guessing, the situation Kazu describes, of contributing to a package, like Haddock, one doesn't maintain nor does necessarily understand deeply, may be another case were the "embrace the slop" aka "slop-as-log dumps" procedure can be fruitful.
The procedure is: 1. tell your user story, why important to you, how urgent 2. name the LLM and any special overrides applied to it 3. give the sloppy blob verbatim, as you'd do with a log 4. state clearly you don't take responsibility for the slop and so you don't propose to merge/apply/follow the slop I've already seen a valuable GHC contribution done this way, via an MR that was understood as never intended for merging, but just an idea and a proof of concept. I think this beats any mixed approaches, e.g., asking the drive-by contributor to fix the slop, which may introduce errors both because the contributor does not necessarily follow all that LLM is doing nor does understand the project that deeply. This only deepens the misunderstanding and masks the mismatch of expectations. The question remains if slop contributions are valuable at all in the context of the scarcity of maintainers of the given packages. I suppose a "no MR is entitled to a review" rule lets the answer emerge naturally. Anyway, what I'm saying is let's avoid at least the part of the LLM contributions friction that comes from misunderstandings. Let's try to clearly distinguish the old style contributions from the new, which are at once a signal of need and urgency and a (possibly misguided) idea and a proof of concept, but not a promise of, through MR coaching, becoming expert enough to land the MR competently. _______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
