A community trust management system based on explicit vouches to participate.
by mitchellhNushell
Last 12 weeks · 176 commits
3 of 6 standards met
observed in https://github.com/conda/rattler/pull/2126#issuecomment-3969570721 workflow: https://github.com/conda/rattler/blob/bb93194fe4cc50eb92976d932c196a316f7f1e3b/.github/workflows/vouch-manage-by-issue.yml, https://github.com/conda/rattler/actions/runs/22463709957/job/65064417973?pr=2126 I would have expected that updates the denounced entry in with the reason provided. Instead, didn't do anything with the message . Probably the same issue holds when vouching (didn't test this)
Repository: mitchellh/vouch. Description: A community trust management system based on explicit vouches to participate. Stars: 3613, Forks: 57. Primary language: Nushell. Languages: Nushell (99%), Nix (0.8%), Shell (0.2%). License: MIT. Latest release: v1.4.2 (1w ago). Open PRs: 2, open issues: 8. Last activity: 1w ago. Community health: 57%. Top contributors: mitchellh, github-actions[bot], alexhraber, faukah, vancluever, dependabot[bot], doprz, meherhendi, trag1c.
instead of writing a CLI dynamically, how about we ship one with this repo? this is required for putting vouch on homebrew, xref https://github.com/Homebrew/homebrew-core/pull/269267#discussion_r2852092812 xref #26 WDYT of this approach @mitchellh? verified it works locally by running . added a test for as well but didn't test this yet
A good point was brought up when we were thinking through implementing the vouch system for the OpenCode repo (we see a lot of AI slop, especially in issues) and someone in https://github.com/anomalyco/opencode/pull/12640#issuecomment-3865765666 brought up the thought of if someone changes their username they would be able to get around being . A bad user (that wants to spam) might change their username to get around being "banned/denounced" from a repo. I think a way to solve this would be to have in the file would be to include the userid of the user as well so that: would become The only caveat to this is since this isn't Github specific (and I don't have experience with other providers like Gitlab) I can't confirm if this is a reliable way to attain user-ids.
Closes #71 Irrelevant for the current state of the PR (so feel free to ignore this entire PR description), but in my issue I said this: I had to deal with this in the past (for Ghostty bot actually lol) so I have a fix ready! What I had to deal with was getting the node ID () from the comment ID present in URLs by manually constructing it. But since we already have the node ID, we can just request the entire comment URL… so yeah, I wasted like 30 minutes on making an explainer diagram for my original solution before realizing it's much simpler 🥲 I don't want it to go to waste, so I'm including it here for fun. Actually -- would it be useful to allow the URL comment ID to be passed into rather than the GraphQL node ID?
This adds the ability to customize the response used for unvouched users when closing pull requests or issues. For both and , the argument allows the ability to supply an optional template for use. This template follows the expansion rules as defined in Nushell's . The default messages for both of these have been moved to a new sub-directory and are now templates themselves, serving as an example for both how to template and also the arguments available (although they have also been documented). has also been added as an argument for the respective workflows. Closes #50.