💡 Community Workflow proposal: Automate ADR labeling and validation workflow

[Scarmonit]

Description

The current CONTRIBUTING.md mentions that ADR (Architectural Decision Records) workflow automation would be beneficial. Specifically, the document states: "(It would be great if some parts of this could be automated. Specification and full workflow required.)"

This workflow suggestion proposes automating the ADR labeling and validation process to reduce manual overhead and ensure consistency.

Objective

Automate the ADR (Architectural Decision Records) workflow by:

1. Automatically adding adr-required or adr-not-required labels based on maintainer/contributor indicators
2. Validating that PRs with adr-required label include an ADR before allowing merge
3. Inheriting adr-required labels from associated issues to PRs
4. Auto-adding adr-included label when ADR is detected in PR

Steps

1. Create GitHub Action workflow that triggers on issue/PR creation and label changes
2. Implement logic to detect ADR assertion by submitter (keywords in body, checkbox in template)
3. Add automatic label inheritance from linked issues to PRs
4. Implement ADR file detection in PRs (scan for files in docs/adr/ directory)
5. Add validation check that blocks merge if adr-required label exists without adr-included
6. Configure bot to comment on PRs requesting ADR if required label is present
7. Add workflow status checks to repository settings

Expected Outcome

• Reduced manual effort for maintainers in tracking ADR requirements
• Consistent application of ADR policy across repositories
• Clear feedback to contributors when ADR is needed
• Automated validation ensures no significant changes are merged without proper documentation
• Improved project governance and decision tracking

Additional Context [optional]

This directly addresses the comment in CONTRIBUTING.md about automation being desirable. Similar automation exists in other large open source projects (e.g., Kubernetes, Rust) and could be adapted for JSON Schema's needs.

The implementation could start with simple GitHub Actions and expand to more sophisticated tooling if needed. I'm willing to contribute to the specification and implementation of this workflow.

[gregsdennis]

ADRs are generally in the spec repo, but I wouldn't be opposed to this kind of automation. Something to consider is how any enforcement might be retriggered if it's determined that a PR should include an ADR after it's been opened. (Ideally that shouldn't happen. We should be determining whether one is required in an issue discussion, but it will happen.)