Congratulations! I'm hooked.
The AI slop block is what I like to learn more about. The FAQ does not include AI slop. Can you elaborate a bit on it please.
We plan to reduce low-quality contributions through several features, some already in place and others still to come. Invite-only registration helps us discourage low-quality accounts and confirm that new members are real people. Next, we plan to introduce a vouching system, similar to Tangled's, that lets contributors build a reputation. We'll combine that reputation with other signals to assess new pull requests and issues. Contributions that appear low quality will be clearly marked and de-emphasized, while maintainers will make the final decision. We also plan to limit how many pull requests and issues a new contributor can open in repositories they don't own. This will be an ongoing effort, but the goal is simple: maintainers stay in control of their queues.
Ironic really because that was the original idea behind Git - to build a tree of trusted developers for the Linux kernel. Linus has those immediately below him that he trusts will push good quality code, and those folks do the same with their group of contributors.
> Invite-only registration helps us
If this is invite-only, then what you're doing is emulating the original strategy of Linus: only certain folks have commit rights. Extend that out to only certain folks have PR-creation rights and you're done. Maintainers select those that can contribute, these folks in-turn, select those that can contribute to the project, rinse and repeat.
Let everyone create issues and implicitly ignore these because any issue that doesn't make it passed the "acceptance level of a maintainer" will naturally be ignored and disappear. As is the case over at GH - issues naturally suffocate because no maintainer gives them air.
Perhaps have a special category "untrusted/toxic PRs" for contributors who don't belong in the tree of trust. These PRs are handled in a toxic-proof containment environment, i.e., they get particular vetting attentions by maintainers. Obviously this would be a path into the "tree of trust" for a project.
Then each project can also implicitly define what is "low quality" for their project - it's how they handle the "toxic PRs".
EDIT:
That's also why branching and forking is so cheap in Git: each sub-maintainer can maintain their own fork with it's branches before pushing up changes to the main fork. (Compare branching using RCS/CVS or Subversion to Git to get a feeling of "cheap" ;))
This can be done over at GH if a fork would be actively maintained by a sub-maintainer and every X days/weeks/months they would push the entire changes of the fork to the main repository. That would be closer to the Linux development strategy - as I understand it.