Define commit standards: authorship, AI attribution, and trailers
@Ethan-Arrowood já está trabalhando nisso.
Desde 10/7/2026.
Avaliação
Esta issue ainda não foi avaliada.
Descrição
Summary
Write a commit standards guideline doc. Initial scope is authorship and attribution — who a commit is credited to and how AI involvement is disclosed — plus an exploration of commit trailers and eventual enforcement. Keep everything in this one issue for now; enforcement work can be split into sub-tasks later once we've settled the guidelines themselves.
Doc outline
1. Authorship and AI attribution
- Every commit must have a human primary author. The
Authorfield is always a person, never an AI agent or bot identity. - AI-generated or AI-assisted commits should attribute the agent via a trailer —
Co-Authored-By:is the current convention (e.g. what Claude Code appends), but the doc should confirm that's the trailer we want, or propose a better-suited one if the ecosystem has converged elsewhere. - Define where the line is: does tab-completion count? Does an agent writing the whole diff? The doc should give practical guidance so people aren't guessing.
2. Trailers: Signed-off-by and the DCO
Explore whether we should adopt Signed-off-by (as used by the Node.js project and the broader Linux/DCO ecosystem):
- What it actually asserts (Developer Certificate of Origin) vs. what commit signing asserts — they solve different problems and the doc should make that distinction clear
- Whether it makes sense org-wide, only for public OSS repos accepting external contributions, or not at all
- If adopted anywhere, when it's most appropriate (e.g. repos with outside contributors where provenance/licensing assertions matter)
- Recommendation with rationale — it's fine for the answer to be "not now, revisit when X"
3. AI agent workflows
These standards should be embedded in agent workflows, not just written down for humans — agents both author commits and review PRs, and skill-level guidance gives us soft enforcement before any tooling exists:
- Producing commits: skills / agent instructions (
skillsrepo,CLAUDE.md/AGENTS.mdconventions) should encode the authorship rules directly — human as primary author, agent attributed via the agreed trailer, plus any trailer conventions we adopt (e.g.Signed-off-bywhere applicable). Agents following the standard by construction is cheaper than catching violations after the fact. - Reviewing PRs: PR-review skills should include a commit-hygiene check — verify authorship/attribution trailers are present and correctly formatted, and flag violations in review output. This is our interim enforcement layer until (and even after) automated linting exists.
The doc should describe this pattern; updating individual skills to implement it can be follow-up work alongside the enforcement sub-tasks below.
4. Enforcement (exploratory — likely future sub-tasks)
We do very little commit linting/enforcement today. The doc should explore options without committing us to rolling them out everywhere:
- Commit message linting (e.g. commitlint, gitlint) — what we'd check (trailers present, author format) and where it would run (CI, merge queue)
- GitHub-side options: rulesets with metadata patterns, required workflows
- DCO enforcement apps/actions if we adopt
Signed-off-by - Explicit note that guidelines can be adopted before enforcement exists — deciding the standard and enforcing it org-wide are separate efforts, and enforcement is a heavier lift we can stage later. Skill-embedded guidance (§3) is the lightweight interim layer.
Acceptance criteria
- Doc added to this repo covering authorship, AI attribution, and the trailer exploration
- Clear recommendation on
Signed-off-by/DCO adoption (including "not yet" as a valid outcome) - AI agent workflow guidance included (agents follow the standard when committing; review skills check commit hygiene)
- Enforcement options surveyed, with candidate follow-up sub-tasks identified but not yet filed
Related
- #12 (commit signing) — signing verifies who pushed the bits; this doc covers how commits are attributed and formatted. The two docs should cross-link.
- Linguagem predominante
- JavaScript
- Estrelas
- 3
- Forks
- 0
- Métricas de merge de PRs
- Nenhum PR com merge em 30d
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Sem modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de HarperFast/code-guidelines
-
Document commit signing: rationale, setup, and org-wide enforcementTalvez livre de novo @Ethan-Arrowood assumiu há 81 dias e não há nenhum pull request aberto. Aberta
HarperFast/code-guidelines#12 · 1 responsável ·
Todas as issues de HarperFast/code-guidelines
Issues semelhantes
-
refactor
Dificuldade 2/5 Meio dia Facilidade para iniciantes 84/100
Mantenedores costumam responder em até 5 dias
-
translation
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
ciderapp/translations#87 · 1 comentário ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 88/100
Mantenedores costumam responder em até 1 dia
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 67/100
Mantenedores costumam responder em até 1 dia
-
component: split-view platform: windows
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 74/100
zen-browser/desktop#15616 · 1 reação ·
Mantenedores costumam responder em até 1 dia