The lab's Macroscope approvability policy: which pull requests Macroscope may approve on its own, and which always wait for a person.
_{Advanced Telerobotics Research Laboratory · Department of Computer Science · Kent State University}

Start here

How it works Where Macroscope reads the policy and how it combines it with its own rules.	What always needs a person Paths and kinds of change that Macroscope never approves.	What can be approved Docs, tests and small fixes that pass their checks.
The policy file .macroscope/approvability.md, the only file Macroscope reads here.	Adding it to a repo Copy the file in and turn approvability on.	Changing the policy Edit here first, then update the repos that carry a copy.

How it works

Macroscope's approvability check decides whether a pull request is safe to approve without a human reviewer. It reads .macroscope/approvability.md from the pull request's latest commit. The front matter sets options; the text below it adds rules on top of Macroscope's built-in criteria, which favor small, low-risk changes and already hold refactors, schema changes, security-sensitive code and breaking changes for a person.

Macroscope has no organization-wide config file, unlike CodeRabbit. Each repo reads its own copy, so this repo is the reference copy that lab repos start from.

The policy runs in strict mode: Macroscope asks for a human review whenever meaningful risk remains, even if CI passes and the change looks correct.

What always needs a person

Macroscope holds a pull request for a human reviewer, without running its eligibility check, when any changed file matches:

Pattern	Covers
.github/workflows/**	CI and deployment workflows
CODEOWNERS	Who must review what, in any folder
.macroscope/**	Macroscope's own config, including this policy

It also asks for a human review of any change that:

• alters research evaluation metrics, ground-truth labels, experimental protocols or reported results;
• introduces or modifies safety-critical robotic control;
• changes credentials, access control or deployment security;
• disables or suppresses static-analysis diagnostics;
• modifies existing behavior without enough verification.

A held pull request is not blocked from merging. To require a person before merge, use branch protection and required reviewers in GitHub.

What can be approved

Documentation updates, tests and narrowly scoped fixes stay eligible for automatic approval when correctness checks pass and nothing material is uncertain. Macroscope never approves a pull request it opened itself.

Adding the policy to a repo

1. Copy .macroscope/approvability.md into the repo at the same path.
2. Turn approvability on for the repo in Macroscope under Settings → Repos.
3. Open the pull request. Macroscope always holds a pull request that adds or edits this file, so a lab member approves it.

To change a few rules for one repo, edit that repo's copy and say why in the pull request.

Changing the policy

1. Edit .macroscope/approvability.md. Front matter keys are case-sensitive; check them against the supported fields. A pattern without / matches at any depth; one with / is anchored to the repo root.
2. Update What always needs a person in this README to match.
3. Open a pull request. Once it merges, update the copies in the repos that carry the policy.

Repo map

Path	What it holds	Read it when
.macroscope/approvability.md	The approvability policy	You want to see or change what Macroscope may approve
.github/assets/	The README header and icons	You restyle this page
LICENSE	The MIT License for this repo	You reuse the policy elsewhere
AGENTS.md	Instructions for coding agents (CLAUDE.md points to it)	You are, or you are directing, a coding agent

Contributing

Suggest a change by opening an issue or a pull request. A change here becomes the starting point for every lab repo, so say why in the pull request. To change what code reviews hold code to, edit dev-guidelines or the CodeRabbit config instead.

License

The policy and docs in this repository are released under the MIT License. The names and logos of the Advanced Telerobotics Research Laboratory and Kent State University are trademarks and are not covered by that license.

---

_{ATR Lab docs · About the lab · Getting started · Dev guidelines · All things ROS 2 · All repositories
Advanced Telerobotics Research Laboratory · Department of Computer Science · Kent State University · www.atr.cs.kent.edu}