Add AI contribution policy.

[sockbot]

Addresses #839

This PR adds portions of Fedora's AI-assisted contribution policy to this project's contribution guidelines. I referenced the final published policy, rather than the proposed policy wordings linked in the discussion.I also incorporated @bunnie 's concerns about AI-assisted contributions reducing the quality of submissions in the AI policy itself.

I chose not to copy the policy wording verbatim as it is licensed CC BY-SA, which is not compatible with this project's contribution guidelines which are checked in to the repo under the Apache license.

Feedback on this PR is welcome.

[bunnie]

seems reasonable to me, i'll let this marinate for a couple days in case anyone wants to comment on it.

[bunnie]

Seems like no objections so i'll probably merge this in a couple days.

[sbellem]

Interesting and insightful take from the rust project: rust-lang/rfcs#3936, centered around the importance of being present to the work being shared, and to those impacted by it.

Contribution policy

Contributing to the Rust Project requires being present — present for the work and present when working with maintainers.

• Effort: Being present means pulling your weight — putting in the same level of effort a maintainer will have to put in to review it. This level varies by the task and by the cost of review, but it's never less than being careful and thoughtful.
• Accountability: Being present means being responsible for everything you send us. We expect you to be involved with the work, to understand it, to be able to explain it, to check it carefully, and to respect our time.
• Compassion: Being present means engaging with reviewers as collaborators. Reviewers take your work seriously and use care and kindness in interactions. Help them help everyone by listening carefully, reflecting, and replying compassionately.

[tunnell]

I have a few pragmatic comments.

• I might suggest having a Github label like "AI-assisted" if there is a feeling some PRs are AI-assisted and some PRs are not. This can help build transparency.
• The CONTRIBUTING.md is pretty generic at the moment. It would be useful to define in more detail what is expected in terms of reproducing bugs and writing tests. Is the emulator enough?

In my experience, a lot of the noise of these systems comes from unclear expectations. A few sentences on what is considered good (or better yet just a link to great examples to emulate) will provide the necessary context to limit some of the worst aspects of AI slop.

The context is this fork which was the result of doing a security audit with Claude Code Opus 4.6 as part of a proof-of-concept research question unrelated to this project. The issues and PRs are currently only toward the fork as I am still parsing the results (i.e. don't meet the accountability criterion above).

Suggestion:

Scope and cadence

• Prefer one concern per PR. Bug fixes, refactors, and documentation updates belong in separate PRs even when they touch the same file.
• For mechanical changes that span many files or services (e.g. pattern sweeps), split into per-target PRs and open no more than two per week so review stays tractable.
• Before a large or cross-cutting change, open an issue or discussion first to align on scope.

[bunnie]

thanks for the review and comment everyone!