add AI tool usage section to CONTRIBUTING.md

[JanFSchulte]

A while ago we discussed the need for an explicit AI code policy for the repository. This is a draft, inspired partially by https://github.com/Qiskit/qiskit/blob/d208387eb226ff4eb0ce6a0e989f3a104650a310/CONTRIBUTING.md?plain=1#L266, which is supposed to serve as a basis for a discussion. So please have a look and give feedback.

Note: Please delete options that are not relevant.

• Documentation update

Tests

Checklist

• I have read the guidelines for contributing.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• I have installed and run pre-commit on the files I edited or added.
• I have added tests that prove my fix is effective or that my feature works.

[JanFSchulte]

Do we want to go even further and require signed commits, like in this example? https://github.com/mlflow/mlflow/blob/master/CONTRIBUTING.md#sign-your-work

[thesps]

I see a typo here: "doesn't violate the lincense" -> license

[vloncar]

As a more concrete suggestion to this PR, I propose we also update the PR template. In general, I would propose the update of all templates, but that's a separate issue to track.

I drafted a template here: https://gist.github.com/vloncar/fd9aacbf6461aff595de9d316c30bda4. It is based on various compiler projects I've been tracking. It includes neat things like suggestions being html comments that are not rendered as opposed to current template that uses pure markdown so whatever instructions user doesn't remove stay indefinitely.

Note that we should add instruction to remove the authorship claim on the commits in the contributing.md guide. Agents cannot claim copyright, and it also pollutes the contributor statistics, even across projects (this was affecting large projects so it is becoming widespread to tell the agent not to put "co-authored by" in the commit messages).

And while we're changing the contribution guide, we should standardize that commits will be squashed when merging and mention that in the guide. Asking people to do this for years has had zero effect, and commits are still mostly nonsensical in most PRs, so let's just forget about that and focus on enforcing PR descriptions to be high quality

[vloncar]

I have pushed a commit to this branch with the concrete changes I proposed above, plus the template rework.

CONTRIBUTING.md

• Fixed three typos and the LICENSE.txt link. @thesps can you check if any typos remain?
• Added that quoted numbers, logs and test results must come from runs the contributor actually performed.
• Added the authorship rule: do not credit an AI tool as a commit author. Authorship carries copyright, which a tool cannot hold, and the trailers distort contributor statistics across projects. Several assistants add Co-authored-by automatically, so it is worth saying explicitly. Disclosure goes in the PR description instead.
• Stated that PRs are squash-merged and that the PR title and description are therefore the permanent record. We have asked for tidy commit history for years with no effect (and admittedly, we didn't follow that ourselves). I'll see if we can make that default for github or perhaps envorce it there (GitLab can do that)
• A pointer to AGENTS.md for contributors using an agent.

Templates

• PR template replaced with the draft I linked earlier
• Issue template(s) converted to YAML issue forms, which gives the chooser and lets us mark fields required. Five categories: bug report, performance or resource usage issue, feature request, plan/RFC, documentation issue, plus links to Discussions for questions and ideas. The bug form asks for the version, frontend, backend and io_type that reports usually omit. The two additions worth a look are the performance form, which asks for part, clock, tool version and which stage the numbers came from, and the RFC form, which gives the "discuss new functionality first" rule an actual front door.

AGENTS.md

A short file at the repository root stating the same expectations in the form agents read, since that is where the behavior actually gets decided. It is deliberately brief because several harnesses inject it into every request.

Regarding signing, I would rather not require it. Sign-off and commit signing are unfamiliar to most of our contributors and neither verifies the thing we care about, which is that a human reviewed the change and takes responsibility for it.

I'll follow this with a PR with agent-facing documentation of how hls4ml actually works, stacked on this branch. This PR sets the expectations; that one gives an agent the knowledge to meet them. The labels performance, rfc and documentation make sense after that.