Skip to content

AI Contribution/Disclosure Policy Template(s) #180

Description

@taladrane

Develop one or more adaptable policy templates open source projects can use to address AI-assisted contributions and vulnerability reports. Tasks include:

  • Analyze AI-specific policies already in use (LLVM, Selenium, Django, etc.)
  • Identify required policy elements relevant to AI-generated submissions (disclosure, human accountability, etc.)
  • Draft policy template(s) that projects can easily adapt, with sections for disclosure, review process, responsibility, and scope
  • Collect community feedback on draft(s); iterate based on input

Deliverable: Published policy template(s) for project maintainers.

Activity

  1. changed the title [-]Draft: AI Contribution/Disclosure Policy Template(s)[/-] [+]AI Contribution/Disclosure Policy Template(s)[/+] on Feb 4, 2026
  2. hellojiaru commented on Jul 29, 2026

    @hellojiaru

    I compared #180 with the maintainer evidence in #178 and the current guide draft
    linked from #179. The guide already covers the major policy elements requested
    here: human accountability, AI disclosure, no autonomous submissions, an
    unchanged quality bar, a working PoC, exact reproduction steps, exploitability,
    and scope. A second broad policy template may therefore duplicate work already
    underway.

    One narrower gap may be worth testing. In #178, maintainers noted that a submitted
    PoC can still be non-working, omit the actual log/result, or be written in a form
    that cannot be reused in the project's test suite.

    Would it help to add a small receiver-verifiable evidence section to the
    existing guide or vulnerability-report template?

    • Claim: the alleged behavior and security impact.
    • Reproduction recipe: exact version, environment, configuration, and
      commands.
    • Observed result: what the reporter actually saw, with a minimal redacted
      output/log excerpt; if not reproduced, say so explicitly.
    • Project fit: map the result to the project's scope and, when practical,
      provide a minimal test, fixture, or source reproduction in the project's
      native tooling.

    For reviewer safety, this should not require maintainers to execute an opaque
    bundle or grant secrets, privileges, or unrestricted network access; maintainers
    choose their own reproduction environment.

    If this distinction is useful, I can turn it into a small edit against whichever
    existing document the working group prefers. If the current working-PoC and
    reproduction-step requirements are considered sufficient, that would also be
    helpful to know.

    Disclosure: I used an AI research/coding assistant to compare the public sources
    and draft this proposal. I reviewed the cited material and take responsibility
    for the comment before posting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions