> It is a mechnical view of open source and collaboration that is focused on > the product, not on the culture from which those products arise. My view is > different... I think it is the human culture from which those ideas and > products originate and Haskell has given a home to many engaged and curious > people. We want to keep those people, whether they use LLMs or not.
I agree that it's a good idea to focus on positive messaging, even just to reach a baseline consensus on the positive portion of the policy, if we can't on the portions that point out some perceived risks and don't point out others. Maybe it makes sense to clearly delimit the two portions? > If we don't express a preference for human authorship, we're effectively > saying "you have to use LLMs so stay relevant". I think this is very clearly > your opinion. It is not mine. Maybe an even lower baseline to start from would be to express appreciation of human (not distinguishing whether LLM-assisted or not) contribution at all, and mark clearly we are not under the same pressures as commercial companies that may decide they can only afford 10x LLM, not bare-human, programmers (I don't suggest here they are right or wrong in doing so nor whether the 10x claim is true). E.g. "we value your contributions, regardless whether they are big and/or frequent or the opposite". A slightly more ambitious next positive message would appreciate quality of contributions, regardless of whether the focus on quality diminishes their volume. Next, value clear attribution of portions of the contributed work with different authorship (treating LLM as "authors" for this purpose) and clear delineation of what the contributor takes responsibility for vs what is taken on authority and trust (e.g,. widely-known published code, a community poll, a formal proof, an LLM review) that may or may not be shared by the GHC reviewers and mtainers. Etc. Only then I'd go into what contributions the GHC maintainers guess have a higher chance of being reviewed and merged, then into what GHC maintainers prefer in the contributions in general and only then what risks they perceive and only then what extra requirements they impose on top of the formal gitlab mechanisms. I'm afraid what I'm proposing is going to make the messaging vague, abstract and verbose, but not as much as if we'd start with ontology, axiology and an exposition of competing worldviews in the community. _______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
