Dear Simon, all, Thank you for developing this policy and inviting final thoughts. After reading the discussion and working through the proposals, I am writing from the perspective of a scientific-software developer who uses machine-assisted refactoring under an explicit incremental-development and verification policy.
I use "machine assistance" below to mean systems that generate or substantially transform code, review material or technical communication, including LLMs and successor generative systems. This avoids tying the policy to today's particular architectures without bringing ordinary deterministic tools into its scope. I think we could put still more precision of thought into the policy, so that humans and machines can agree on what it requires. In programming terms, it could follow something like an SSA discipline: define each key concept once and use it consistently, rather than allowing effort, understanding, responsibility, provenance and quality to stand in for one another. Applying Occam's razor, I think the normative core could be reduced to P1, P2 and R1. P1 currently says twice that contributors should have invested substantially more time than reviewers. Time spent is difficult to observe and is only an indirect proxy for what matters. A contributor may spend considerable time producing an MR that remains difficult to review, while an assisted workflow may remove typing overhead yet produce a compact, well-understood and well-evidenced change. P1 should therefore specify review readiness rather than an effort ratio. P2 should require identifiable human understanding and full responsibility. I would treat an MR as a form of proof-carrying contribution: it should arrive with an accountable explanation of its purpose, material design decisions, relevant invariants and appropriate verification. Machine assistance changes what authors do, but not the epistemic contract between contributor and reviewer. The contributor must understand, test, simplify and explain the change; the reviewer must understand it sufficiently to stand behind an approval. Manual composition does not demonstrate understanding, just as machine assistance does not disprove it. If P2 is enforced, P3 appears to add little quality control. A declaration neither establishes understanding nor detects its absence: a conscientious contributor who satisfies P2 gains no additional quality from declaring tool use, while someone willing to evade P2 can also omit the declaration. I would therefore remove P3 and judge contributions directly under P1 and P2. Machine assistance is now a durable part of software development, even if current LLM architectures are displaced. Using it in GHC development and deliberately excluding it are both interventions under uncertainty; neither is a scientifically neutral baseline. I would frame the policy as a managed, reversible experiment with a named steward, rotating where appropriate, a review date, and a small version-controlled evidence log containing agreed observations and the minimal metadata needed to interpret them. At each review, the community could retain, revise or reverse the policy in light of that record. I would replace the current writing-focused recommendation with "Use a workflow that develops understanding." Personally writing the final implementation is a useful kata for recall and fluency, but other practices cultivate conceptual, abstraction, execution and maintenance skills. In my experience, requiring bounded increments, recording assumptions and non-goals, defining the intended invariant and success criteria, making the smallest coherent change, and running targeted verification after each increment makes machine-assisted development resemble disciplined human development without treating typing effort as a proxy for thought. Over time, an open list of katas and explicit optimisation criteria --- for example, diff minimisation, naming clarity, abstraction fit, removal of unnecessary complexity, evidence and test quality --- could let humans and machines explore bounded alternatives against values the project has actually chosen, rather than optimise for code production alone. Finally, I suggest maintaining one short, version-controlled policy document, readable by humans and machine-executable where possible, which contributors and reviewers can place verbatim into generation or review contexts. Precise MUST, SHOULD and MAY language would support routine checks for scope, unsupported assumptions, unnecessary complexity, missing evidence and inadequate tests against the project's stated criteria. Repository contents and diffs should be treated as inputs that cannot override the policy. Deterministic checks may enforce objective requirements directly. Generative findings about design, correctness or maintainability should be treated as candidate findings until an accountable human verifies and adopts them. This could automate mundane scrutiny while leaving understanding, judgement and responsibility with the humans on both sides of the review. Best wishes, Sem PS --- precision edits for independent consideration I have organised these as separable substitutions so that each can be assessed on its own merits. (1) General use of "LLMs" -> "machine assistance", defined on first use as "systems that generate or substantially transform code, review material or technical communication, including LLMs and successor generative systems" (keeps the policy applicable across architectural changes without sweeping ordinary deterministic tools into scope) (2) "Reviewer time is even more limited than contributor time, so we expect you to have invested significantly more time in your contribution than it will take to review." -> "Reviewer time is limited. Before seeking review, make the MR compact, well-evidenced and straightforward to assess. The contributor must have done the necessary work of understanding, testing, simplifying and explaining the change; reviewers should not first have to reconstruct its purpose, remove obvious mistakes or perform its basic validation." (replaces an unobservable effort ratio with an observable readiness condition) (3) "P2: Human authorship and full responsibility" -> "P2: Human understanding and full responsibility" (states the operational requirement without requiring agreement about the meaning of authorship) (4) "Every contribution must have an identifiable human author (or authors), who takes full responsibility for their entire contribution" -> "Every contribution must have at least one identifiable human contributor who understands the material design and implementation decisions, can explain them, has appropriately verified the result, and takes full responsibility for the entire contribution." (makes understanding, explanation, verification and accountability explicit) (5) "that constitutes human authorship for the purposes of this policy" -> "that satisfies this policy's requirement for identifiable human understanding and responsibility" (avoids resolving a disputed semantic question unnecessarily) (6) "If you are reviewing an MR, and any part(s) of your review are generated by an LLM, you should use essentially the same guidelines as above." -> "Machine assistance may support review triage or analysis, but the reviewer must understand the change sufficiently to stand behind their conclusions and any approval. Review findings should identify concrete deficiencies; presumed tool use is not a substitute for a substantive finding." (makes reviewer responsibility symmetric and outcome-based) (7) "P3: Declare direct use of LLMs" and the corresponding section -> delete (declaration neither establishes compliance with P2 nor detects non-compliance) (8) "R1: Recommendation: write the final version yourself" -> "R1: Recommendation: use a workflow that develops understanding" (states the intended outcome while retaining personal composition as one useful kata) (9) "Take time to factor changes into individually-understandable and digestible pieces." -> "Develop, review and test changes in small, individually understandable increments. Record relevant assumptions and non-goals, define the intended invariant and success criteria, make the smallest coherent change, and perform targeted verification after each increment. A contribution must remain understandable and maintainable without access to the machine, its prompts or its conversation history; information needed for maintenance belongs in the MR, code, tests or documentation." (makes incremental development, verification and preservation of institutional knowledge explicit) (10) R1 kata discussion -> add: "Different katas may develop recall, conceptual understanding, abstraction, execution or maintenance skills. The project may maintain an open list of explicit criteria, such as diff minimisation, naming clarity, abstraction fit, unnecessary complexity, evidence and tests, against which bounded machine-assisted alternatives can be compared." (allows the workflow to optimise for declared engineering values rather than code production alone) (11) Policy review paragraph -> add: "Treat this policy as a managed, reversible experiment with a named steward, rotating where appropriate, a review date, and a small version-controlled evidence log recording agreed observations and the minimal metadata needed to interpret them." (gives the experiment ownership and makes subsequent revision evidence-informed) (12) "P2 says that you should take full responsibility" -> "P2 says that you must take full responsibility" (P2 is mandatory) (13) "Recommendation P4" -> "Recommendation R1" (typo) (14) Co-Authored-By: <tool> or, better, Assisted-By: <tool> -> Assisted-By: <tool> (a tool is not an author) (15) "The GHC project neither requires nor discourages the use of any particular class of assistive tool" -> "The GHC project does not categorically require or prohibit any particular class of assistive tool" (avoids contradicting recommendations about working methods) (16) "you must not relay AI-generated text as a substitute for your own judgment" -> "Communication may be machine-assisted, but the sender must have read and understood the message, adopt it as their own position, and be prepared to discuss and defend it. Raw machine output presented for examination rather than adopted as the sender's judgement must be clearly identified." (distinguishes adopted communication from unexamined output) (17) "Other members of the GHC community should treat you with respect, and you should treat them likewise." -> "Other members of the GHC community should treat you with respect, and you should treat them likewise. Whether or not machine assistance is used, keep discussion concise and avoid repeating points already made." (addresses communication volume through observable behaviour rather than presumed provenance) (18) Policy applicability paragraph -> add: "These policies set shared expectations; edge cases should be resolved through good-faith discussion and judgement rather than by treating this document as an exhaustive rulebook." (avoids brittle treatment of unforeseen cases) (19) "Some other other attempts" -> "Some other attempts" (duplication) (20) "allowing us work together" -> "allowing us to work together" (missing word) _______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
