## TL;DR
Ask one question before any outreach or automation that touches someone else's project: if the maintainer watched a replay of what you are about to do, would they be glad it happened? If the honest answer is yes, proceed; if it is maybe, ask first; if it is no, do not do it. The test works because it replaces abstract ethics with a concrete human reaction you can actually predict.

```text
what "would the maintainer be glad" means in practice
```

## Use this when
- You are about to post, file, or automate something on someone else's project
- You are briefing an agent that takes autonomous outreach actions
- A tactic feels effective but slightly off and you need a check
- You are writing the ethics section of an outreach playbook
- You need a shared standard the whole team can apply without you

## Not for this skill when
- You need legal permission (licenses and terms, not vibes)
- The maintainer explicitly invited the action (invited beats the test)
- You are judging a competitor's behavior (apply it to yourself first)
- The question is about internal team actions with no external party

## Steps
1. Name the maintainer as a specific human, not "the community". Picture the person who merges the PRs or moderates the forum reading your action in full context. Abstractions let you off the hook; a specific tired human at 11pm does not.
   ```text
   the maintainer is: [name or handle], their context: [one line]
   ```
   Expected output: a named human. Success check: you feel slightly more careful already, which means it is working.

2. Replay the action from their side, worst-case framing included. Not your intent, their experience: a notification at midnight, the tenth identical issue this week, a thread that now needs moderating. Gladness is judged on experience, not intent.
   ```text
   they experience: [what lands in their inbox/feed/queue]
   at this volume: [what happens if ten agents do it]
   ```
   Expected output: an honest replay. Success check: the "if ten agents did it" line is filled in, because scale is where gladness dies.

3. Score it: glad, ask-first, or no. Glad means proceed. Ask-first means the action might be welcome but the manner needs consent; send the one-line ask. No means stop, no matter how effective the tactic looks on paper.
   ```text
   verdict: [glad | ask first | no]
   if ask-first: the ask sent: [date]
   ```
   Expected output: a verdict per action. Success check: some actions score "no" and get dropped, or you are not being honest.

4. Write down the verdicts that recur. Common actions get precedents: summarizing messy threads is usually glad, auto-filing issues is usually ask-first, mass mentions are usually no. Precedents turn the test from a meditation into a lookup.
   ```text
   precedent: [action] -> [verdict], set [date]
   ```
   Expected output: a growing precedent list. Success check: new team members apply past verdicts without re-deriving them.

5. Revisit precedents when context changes. A tactic that was glad at small scale can become unwelcome at ten times the volume; a maintainer who welcomed automation may burn out. The test is continuous, not a one-time certification.
   ```text
   precedent review: quarterly, changed: [list]
   ```
   Expected output: dated reviews. Success check: at least one precedent flipped after a scale or context change.

## Variant phrasings
### The maintainer gladness test explained
Explainer phrasing. Steps 1 through 3: name the human, replay their experience, score it.

### Ethical check for automated outreach
Outreach phrasing. The test as a gate in the outreach workflow; "ask first" is the most common verdict for automation.

### Would the maintainer be glad examples
Example phrasing. Passing: a concise summary of a 200-comment thread posted once. Failing: the same summary posted to ten related repos uninvited.

### Permissionless contribution ethics
Philosophy phrasing. The test draws the line: permissionless does not mean consequence-free, and gladness is the consequence that matters.

## Why it happens
Outreach ethics usually fail on abstraction: "providing value" and "driving awareness" sound good until a specific human has to triage the result at midnight. The test collapses the abstraction by forcing a concrete prediction about a concrete person's reaction, which humans are surprisingly good at. It also scales: "if ten agents did it" catches the tactics that are fine once and terrible as a norm.

## Edge cases / pitfalls
- Maintainers differ. What delights one annoys another; when in doubt across a category, "ask first" is the verdict, not "glad".
- Gladness is not the same as permission. A maintainer can be glad you did something you still should have asked about; use the test for judgment, not as a legal theory.
- Do not use the test to justify something after doing it. Applied retroactively it becomes rationalization; the value is entirely in applying it before.
- The test cuts against your own incentives by design. If it never tells you no, you are asking it wrong.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5ebWG2a7QjpMfI0ALkIG-A