Hi, Teo!

I completely understand your concerns and their justifications.

That said, an advantage of the shared statement over the draft policy
is, in my opinion, that the shared statement stresses jointly-held,
positive values more and more strongly points out the risks of LLM use
with regards to these values. Yes, you could say that it “allows” more
than the draft policy, but this is because it’s not a policy and
therefore doesn’t regulate the details. When respecting the message of
the shared statement, one should find that lots of things around LLMs
are rendered non-permissible or at least highly questionable by it.

Also, don’t forget that in the end the draft policy didn’t have so much
support from the “anti-LLM” side anymore, because it had been watered
down.

Maybe, I’m not seeing this issue clearly. I must say that I can’t afford
anymore spending time to think more deeply about all those policy
proposals and statements and I’m actually pretty sick of this whole
discussion. An advantage of the shared statement for me is that it seems
clear to me what its message is. The draft policy, with its detours into
various facets, rather confuses me.

All the best,
Wolfgang

Am Mi 29.07.2026 10:54 schrieb Teo Camarasu:
> Hi folks,
>
> I would be strongly opposed to adopting this shared statement instead
> of a policy.
>
> The way I read it, this shared statement is actually an extremely weak
> document. It mentions some of the harms from LLMs but many of the
> negative aspects from Simon’s draft are completely dropped. It also
> fails to connect any of these harms to its very weak policy
> suggestions.
>
> This is also a significant step back from the existing policy
> <https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing/AI>. This
> policy specifies that:
>
> > Contributors should only put forth contributions that they could
> > have created without the support of AI tooling.
>
> To drop this completely would be a large step back.
>
> I’m also very confused about the notion that attribution is a way of
> “protecting” the no-LLM side. While some people might hold this view,
> it doesn’t seem like the dominant position I’ve seen in this
> conversation so far. The main thing I’ve seen is that people want
> attribution because it allows them to review LLM generated code with
> an extra keen eye.
>
> I think it also doesn’t do a very good job of portraying the anti-LLM
> position in that paragraph. While some people merely dislike seeing
> LLM output, for others there are stronger objections to LLM use and
> the tone comes could do with improvement.
>
> Is the intention that if a user does one of the things in
> “inappropriate use” that they’re contribution would be rejected? These
> seem like extremely controversial suggestions to me, and also things
> that are very difficult to tell.
>
> My impression is that Simon’s draft while not satisfying everyone was
> close to being ready to be adopted. A great deal of time and debate
> has gone into making it.
>
> Adopting a weak statement and kicking the difficult task of figuring
> out the policy (which is mostly done!) down the road is unlikely to
> make this task easier in the future. I think this long drawn out
> process has already alienated a lot of people from engaging in
> discussion, and restarting the process from scratch doesn’t sound like
> a wise idea to me.
>
> Cheers,
> Teo
>
> On Wed, 29 Jul 2026, at 10:34 AM, Wolfgang Jeltsch wrote:
> > Am Mi 29.07.2026 11:44 schrieb Julian Ospald via ghc-devs:
> > > But my feeling is that we got sidetracked from the essence of our
> > > disagreement while descending into the depths of policy
> > > specifications.
> >
> > Exactly. And therefore I have the following idea: We could start
> > with the shared statement and perhaps install a concrete policy
> > later. This approach would acknowledge that we haven’t reached
> > agreement on various concrete points, and it could shape any
> > discussion about these. With the shared statement in place, we could
> > also make any policy crisper, as we could focus on a few, simple
> > rules instead of giving rules and also the motivation for these
> > rules.
> >
> > What are your thoughts on this?
> >
> > All the best,
> > Wolfgang
_______________________________________________
ghc-devs mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to