Should General have a guideline or rule preventing registration of vibe-coded packages?

[ericphanson]

I think allow for a `deprecated` table in a `Package.toml` in a registry by KristofferC · Pull Request #4433 · JuliaLang/Pkg.jl · GitHub is pretty similar to your suggestion here, although that PR doesn’t prohibit using deprecated packages on newer Julia’s, it just flags them and prevents autocomplete.

[Palli]

@ChrisRackauckas

I don’t see why vibe coded packages should be singled out. …
The rule should be just about quality. As long as it’s documented, well-tested, does what it says, solves a real problem, is something others would use, and is licensed correctly it’s an accept. How you get to that level of quality really doesn’t matter.

@goerz

vibe-coded packages are starting to become a bit of a problem

I don’t see auto-registration as some kind of right, and I think just asking if AI used, then disable it would be ok. Or give a longer period then. I’ve stopped a package being registered that was just spam, but such a rule wouldn’t prevent that… It’s hard to judge quality, and e.g. intriguingly it’s not about a metric, at least this one higher:

Making your code base better will make your code coverage worse - Stack Overflow

[goerz]

Anybody is free to block the automatic registration of a package simply by leaving a comment on the registration PR that does not contain [noblock].

We try to consider registrations in good faith, aiming for consensus as much as possible. The bot is just to catch some basic issues, but can be overridden. Likewise, any concerns about LLM usage or any other “quality issues”.

At the end of the day, we try to foster a healthy ecosystem of packages, not blindly apply some set of “rules”.