Is there a well-known badge / notice / whatever indicating "no LLM contributions" that one can put on a repository?

@meejah
Host on Codeberg? Half-joking, but would be good to know if there is one.

@jbowen yeah, I've been playing with git-bug a little, have a couple repos on sr.ht and have definitely considered codeberg for some things as well.

I _really_ wish there'd been some more progress on "federated PR/MRs" by now (I haven't unfortunately translated any of that wishing to code on my part however).

But wait, does CodeBerg itself have a policy against LLM use on hosted projects?? Looks like YES! See https://blog.codeberg.org/protecting-our-floss-commons-from-llms.html

@meejah @jbowen I believe sourcehut does too!

@jbowen p.s. for anyone actively using codeberg currently, how does a contributor coming from GitHub interact? Do you just lose those contributors, or ...?

I guess I should just move at least one personal project to Codeberg and see how it works.

Ideally I think I'd host issues with "git-bug" and use their bridges to pull/push stuff from "where the people are at", i.e. BOTH GitHub and Codeberg.

@meejah Would a badge that links to a scan of your repo at https://slopscore.ava.pet/ work for you? (Doesn't exist currently but it's a feature request)

@liberty @meejah
sr.ht is where all my personal repos are and is what I consider my "home" forge, but I didn't know if they'd fully banned LLM projects.

@meejah (and also shows its score)

@liberty first I've heard of this (neat project!) and probably a "yes" from me.

Obviously that's not _quite_ what I was asking about, but thanks!

(I'm more looking for a like "here's a cogent explanation / rant / manifesto that I agree with on why I'm not accepting LLM contributions" if such a thing exists)

@jbowen @meejah I'm thinking of this: https://sourcehut.org/blog/2026-08-27-tos-changes-and-llms/

@jbowen @liberty Happy to see these policies emerging!

I do have a couple small personal projects on sourcehut, am a subscriber, and generally like the vibe and UI.

The "PR" workflow is a little .. weird (unless you've done like kernel or other mailing-list based dev) so I'm not sure how well that would serve a "large" project that's been on github for a long time .. mostly thinking of the Issues, PRs etc

"git-bug" works nicely from my tiny experiments though

@meejah
Like anything where you need an account (vs. email-based patches/contributions), there might be a bit of a barrier in the form of registering for folks wanting to contribute/participate fully on a platform, but I don't think for most it's a big deal. Codeberg also has a familiar feel for folks coming from GitHub or GitLab.

Some projects are pretty liberal and mirror to GitHub and will take patches submitted there. It's really up to the project.

@meejah Oh. I just link to a code of conduct adapted from Zig's. A longer explanation may also be more helpful too.

These also might be of use as far as badges GI:

https://cadence.moe/blog/2024-10-05-created-by-a-human-badges

@jbowen yeah, CodeBerg does seem the most familiar for people wanting to click their way to a PR (i.e. most contributors). They also have github + gitlab federated login, so that reduces the friction too.

Do you know if there's a migration script for "github -> codeberg" for issues / PR history?

(I'm ignoring GitLab since they seem to be on the "all in" side of the LLM fracture)

@meejah @liberty
Yeah, Codeberg is where I'd host something I was expecting/wanting broad public participation in.

I personally like the email-based workflow (I also use aerc for email), but I'm aware of the reality that most people want a nice web UI and that I'm a weird old man.

@jbowen p.s. if anyone wants to "practice" I'm happy to take human contributions to https://git.sr.ht/~meejah/git-withme on sourcehut!

@jbowen @liberty to be fair, the "click your way to a PR" does work decently well on sourcehut (but I'm not sure if it works at all for non-registered users).

@meejah
> Do you know if there's a migration script for "github -> codeberg" for issues / PR history?

I do not, but that's a good question for the fedi hive mind!

@meejah @liberty
Oh, I'll have to give it a shot. I've never actually tried, lol.

@meejah @jbowen https://docs.codeberg.org/advanced/migrating-repos/

@meejah

You can try this one:

https://hinokodo.itch.io/human-made

I personally have been putting more explicit categories -- nothing, busywork only (commit messages, for example), only identifying bugs, etc. with a simple block in the README and a simple image button.

The hive mind never fails! Thank you, @cybercow!

I'm sure someone would appreciate a CLI scripty thing, or perhaps a nice TUI (side topic, but I've enjoyed the (non-LLM) CLI/TUI Renaissance with Rust, Go, and Zig projects.

@meejah

@meejah
Back to this one, but

> But wait, does CodeBerg itself have a policy against LLM use on hosted projects?? Looks like YES!

is absolutely why I suggested it (and I've enjoyed the conversation that's flowed from it!

@jbowen @cybercow All of these forges have a shared, core problem: their "issues" / bug / tickets / todo databases are all different.

I've played with https://github.com/git-bug/git-bug a bit recently, and it works pretty well.

What would be super cool is if forges like codeberg grew the ability to interop with them -- so that the "issues" for a git-bug using repo directly displays and edits git-bug data. Makes it even easier to make "git" the canonical source of data, multiple front-ends, migration, ..

@meejah @jbowen @cybercow are you familiar with @monsieuricon 's efforts to integrate git-bug into the Linux kernel mailing list infra and surrounding tooling?

E.g. here is a direct link to the git-bug entries contained in the b4.git repo: https://git.kernel.org/pub/scm/utils/b4/b4.git/bugs/ - tucked in nicely with the rest of the basic git web UI.

It's basic, robust, and I really hope it catches on.

@gnomon @meejah @jbowen @cybercow I don't think an avowed anti-LLM project would be interested in any of my work.

@monsieuricon I meant to point it out as an example of a project building a UI atop bit-bug rather than a project to incorporate wholesale, but you do make a good point.

@gnomon @jbowen @cybercow @monsieuricon I was not, thanks! Looks promising for sure.

(Maybe the *exact current* git-bug format isn't optimal / generic enough but the idea of "(open-format) data in git" I sure hope catches on more)