Introduce the Vouch/Denouncement Contribution Model

[mitchellh]

This moves Ghostty to a vouch-based contribution system. The high-level idea is that only vouched users can participate in contributing to Ghostty. Users are vouched by maintainers commenting "lgtm" on an issue they opened.

The system also supports explicit denouncement: bad actors can be added to the denounced list which blocks them from contributing entirely. We maintain this as a public record so other projects can adopt our prior knowledge about bad actors if they choose. In this PR, only maintainers can denounce by responding denounce, denounce [user] [reason] to any issue or PR.

This also updates our contribution guidelines and templates to fit this new model.

This system is inspired very heavily by Pi. The original commits were based directly on their work.

Important

This is experimental. We're going to continue testing and refining this. It isn't a perfect system [yet]. This PR just adds the basics so we can start proving it out.

Why?

Open source has always worked on a system of trust and verify.

Historically, the effort required to understand a codebase, implement a change, and submit that change for review was high enough that it naturally filtered out many low quality contributions from unqualified people. For over 20 years of my life, this was enough for my projects as well as enough for most others.

Unfortunately, the landscape has changed particularly with the advent of AI tools that allow people to trivially create plausible-looking but extremely low-quality contributions with little to no true understanding. Contributors can no longer be trusted based on the minimal barrier to entry to simply submit a change.

But, open source still works on trust! And every project has a definite group of trusted individuals (maintainers) and a larger group of probably trusted individuals (active members of the community in any form). So, let's move to an explicit trust model where trusted individuals can vouch for others, and those vouched individuals can then contribute.

Web of Trust

The VOUCHED file is purposely a basic, single, flat-file system that is easy to manipulate with any standard POSIX-tooling or mainstream languages without any external libraries.

I hope that eventually projects can form a web of trust and share and ingest VOUCH files from other projects they trust in order to get a better default trust model across projects in the age of relentless AI attack.

The file also specifically is relaxed on the exact policy for being vouched or denounced. If/when another project decides to trust an upstream vouch file, they're expected to do the diligence to understand if they also trust the upstream projects reasoning for vouching/denouncing. For example, if someone decides to create a vouch file promoting their friends or denouncing their own personal shitlist, that's fine, but downstreams can be aware of that and not trust it.

A Generic System

The vouch system is implemented as a standalone project currently in .github/vouch. It is forge-agnostic but includes GitHub integration to start. I plan on expanding this. My goal is that if this works for us, other projects can quickly adopt it. I don't want to extract this out to its own repo or generalize it more until we prove out the edge cases with our usage. But, I will welcome contributions here to improve this system.

Usage

Local files only:

• vouch.nu check <user> - check if a user is vouched/denounced
• vouch.nu add <user> - add a user to the vouched list
• vouch.nu denounce <user> - denounce a user

GitHub integration:

• vouch.nu gh-check-pr <pr> - check PR author status, optionally auto-close
• vouch.nu gh-manage-by-issue <issue> <comment> - vouch/denounce via issue comments

[mitchellh]

This is purposely starting out empty so I can test it a bit more. Then I'll add a number of people who have previously contributed. Maintainers don't technically need to be on here but probably a good idea.

[00-kat]

Also recognizing would be a cute touch.

[mitchellh]

Realistically, we should make the acceptance text configurable via flags for the Nu script. So projects can use whatever.

[mitchellh]

I went ahead and preemptively added support for the optional platform: prefix along with support in the Nu tooling.

[SamBWagner]

I'm not a maintainer, nor someone who engages with this repo...

But this is sick! :)

[rhodes-b]

This moves Ghostty to a vouch-based contribution system. The high-level idea is that only vouched users can participate in contributing to Ghostty. Users are vouched by maintainers commenting "lgtm" on an issue they opened.

"issue" is meant to be a PR here?
or is #3558 going to change?

edit: reading the PR more it does seem like that will change. Issue triage / bugs should still created as discussions?
I still didn't read much yet but I think that should be explicit

[mitchellh]

edit: reading the PR more it does seem like that will change. Issue triage / bugs should still created as discussions?
I still didn't read much yet but I think that should be explicit

Yeah that's the idea. It is a good point though and I don't want to confuse people. The automation here only handles issues and not discussions [yet]. Any thoughts?

[lightningRalf]

Yeah that's the idea. It is a good point though and I don't want to confuse people. The automation here only handles issues and not discussions [yet]. Any thoughts?

Wrt discussions, you might need a two tiered approach with something like lg (looks good) so the person gets onto a pre vouch list, so he is allowed to create an issue in the first place.

[cristeahub]

edit: reading the PR more it does seem like that will change. Issue triage / bugs should still created as discussions?
I still didn't read much yet but I think that should be explicit

Yeah that's the idea. It is a good point though and I don't want to confuse people. The automation here only handles issues and not discussions [yet]. Any thoughts?

Having every issue be actionable feels valuable, losing that shouldn't be taken lightly imo.

If both issues and discussions are supported a new contributor could comment on an issue "I want to do this" and get vouched, and if it's a new feature one could open a discussion (just like now) and get vouched via that discussion.

Given the volume on discussions I am afraid having issues as the main way to get vouched could cause a barrage of issues being created, cluttering the set of actionable issues that the current issue list is.
This might only be true in the start though, you did see a massive influx of discussions when moving away from issues for discussion which I am sure has calmed down.

[mitchellh]

I updated the PR:

• Use the upstream mitchellh/vouch
• Vouch requests now go in the dedicated vouch request discussion category, with a template in this PR
• We now gate issues on vouched users so drive-by issues are no longer possible, either!
• Maintainers use !vouch, !denounce, and !unvouch

[danielwe]

Looks like the keyword should be updated from lgtm to !vouch in the template and guidelines? (Apologies if I misunderstood.)

[mitchellh]

Ah yeah that was a holdover. Fixed up.