Vouch Expiration and Activity Based Auto Renewal

I was just thinking about this and instead of adding to the td file, I think we should add a GitHub action that goes through the list and just unvouches people who haven't been "active" (by some definition) for a certain amount of time, determined via API calls.

Active definitions could be:

• Commented anywhere (issue, PR, discussion)
• Opened an issue or PR
• Committed

This can be built in this way:

• Update vouch/github.nu to add a new gh- function to do this, like gh-prune-inactive
• Flag --check ["comment" "issue" "pr" "discussion" "commit" ...] (takes a list of strings) of what dimensions to check

I was just thinking about this and instead of adding to the td file, I think we should add a GitHub action that goes through the list and just unvouches people who haven't been "active" (by some definition) for a certain amount of time, determined via API calls.

Active definitions could be:

• Commented anywhere (issue, PR, discussion)
• Opened an issue or PR
• Committed

This can be built in this way:

• Update vouch/github.nu to add a new gh- function to do this, like gh-prune-inactive
• Flag --check ["comment" "issue" "pr" "discussion" "commit" ...] (takes a list of strings) of what dimensions to check

I was just thinking about this and instead of adding to the td file, I think we should add a GitHub action that goes through the list and just unvouches people who haven't been "active" (by some definition) for a certain amount of time, determined via API calls.

Active definitions could be:

• Commented anywhere (issue, PR, discussion)
• Opened an issue or PR
• Committed

This can be built in this way:

• Update vouch/github.nu to add a new gh- function to do this, like gh-prune-inactive
• Flag --check ["comment" "issue" "pr" "discussion" "commit" ...] (takes a list of strings) of what dimensions to check

How would this apply to other source forges or independent repositories?

How would this apply to other source forges or independent repositories?

How would this apply to other source forges or independent repositories?

You'd use the Nu CLI/API to write forge-specific automation in the same way we have gh- prefixed automations for GitHub.

You'd use the Nu CLI/API to write forge-specific automation in the same way we have gh- prefixed automations for GitHub.

You'd use the Nu CLI/API to write forge-specific automation in the same way we have gh- prefixed automations for GitHub.

This is a great direction. The prune-by-activity approach via gh-prune-inactive is clean — it keeps the .td file as the single source of truth and avoids adding timestamps to the format.

One thing I'd suggest considering: a grace period between "inactive" and "pruned." In a project I work on we use a three-state lifecycle for trust-like entries:

active → stale → removed

• active: normal state, passes all checks
• stale: hasn't met activity threshold, but still trusted (grace window — e.g., 30 days)
• removed: pruned after grace expires

The grace period matters because contributors sometimes go dormant for a few months and come back. Without it, a returning contributor gets blocked on their first PR back, which feels punishing.

Implementation-wise this could be lightweight — gh-prune-inactive could have a --grace-days 30 flag. On first detection of inactivity, it adds a comment to an tracking issue (or logs it). On next run after grace expires, it actually unvouches.

The --check dimension list is flexible enough to handle this — you could even weight dimensions differently (a commit counts more than a comment for "still active").

Happy to help implement if this direction makes sense.

This is a great direction. The prune-by-activity approach via gh-prune-inactive is clean — it keeps the .td file as the single source of truth and avoids adding timestamps to the format.

One thing I'd suggest considering: a grace period between "inactive" and "pruned." In a project I work on we use a three-state lifecycle for trust-like entries:

active → stale → removed

• active: normal state, passes all checks
• stale: hasn't met activity threshold, but still trusted (grace window — e.g., 30 days)
• removed: pruned after grace expires

The grace period matters because contributors sometimes go dormant for a few months and come back. Without it, a returning contributor gets blocked on their first PR back, which feels punishing.

Implementation-wise this could be lightweight — gh-prune-inactive could have a --grace-days 30 flag. On first detection of inactivity, it adds a comment to an tracking issue (or logs it). On next run after grace expires, it actually unvouches.

The --check dimension list is flexible enough to handle this — you could even weight dimensions differently (a commit counts more than a comment for "still active").

Happy to help implement if this direction makes sense.

This is a great direction. The prune-by-activity approach via gh-prune-inactive is clean — it keeps the .td file as the single source of truth and avoids adding timestamps to the format.

One thing I'd suggest considering: a grace period between "inactive" and "pruned." In a project I work on we use a three-state lifecycle for trust-like entries:

active → stale → removed

• active: normal state, passes all checks
• stale: hasn't met activity threshold, but still trusted (grace window — e.g., 30 days)
• removed: pruned after grace expires

The grace period matters because contributors sometimes go dormant for a few months and come back. Without it, a returning contributor gets blocked on their first PR back, which feels punishing.

Implementation-wise this could be lightweight — gh-prune-inactive could have a --grace-days 30 flag. On first detection of inactivity, it adds a comment to an tracking issue (or logs it). On next run after grace expires, it actually unvouches.

The --check dimension list is flexible enough to handle this — you could even weight dimensions differently (a commit counts more than a comment for "still active").

Happy to help implement if this direction makes sense.

Ough. Got the vibes of an AI-written comment, so I took a look at the profile and it seems the most recent repositories were significantly co-authored by AI and in languages the author doesn't seem at a glance to primarily write in. Also, this just seems like a redeclaration of the "trust decay" idea.

I am not ready to extend my vouch yet.

Ough. Got the vibes of an AI-written comment, so I took a look at the profile and it seems the most recent repositories were significantly co-authored by AI and in languages the author doesn't seem at a glance to primarily write in. Also, this just seems like a redeclaration of the "trust decay" idea.

I am not ready to extend my vouch yet.

I want to 'vouch' for the grace period idea, I think it's pretty important.

As this thing catches on, being vouched for this or that project is a human status. Speaking on behalf of humanity, we take status very seriously. Specifically, being vouched is a status accreditation: like a merit badge or a promotion. Being un-vouched, therefore, is a status degradation: like being stripped of rank. As the original chatbot-enhanced reply puts it: punishing.

And then it's a lot to keep track of, on top of that. Every project will have its own criteria, including how long before inactivity un-vouches: and that itself will probably end up fairly fine-grained, just within a project. I'm sure it's easy to recognize that we might want collaborators who won't lose that status on the basis of mere wall-clock time. As a reductio ad absurdum, imagine getting locked out of your own project just because it hasn't needed your attention lately.

So I would not expect most people to keep independent track of all that: but it's easy to set up a notification of a change in status. How would you prefer your absent collaborators be reminded of your existence: a message which kicks them off the project, or one which says "hey we haven't seen you in awhile, do you want to stay involved or not"?

Because at that point, if they let it expire, it's their choice: which is not a status degradation, just a change in status. Difference between retiring and getting laid off, approximately.

If the option of a grace period exists, I predict almost everyone will use it, for the above reason. If it doesn't, this will result in avoidable hurt feelings.