# Policies around registering AI-created packages in General?

**URL:** <https://discourse.julialang.org/t/policies-around-registering-ai-created-packages-in-general/136228>\
**Category:** Tooling\
**Tags:** package, registry, ai\
**Created:** [March 16, 2026, 4:25pm UTC](https://discourse.julialang.org/t/policies-around-registering-ai-created-packages-in-general/136228 "2026-03-16T16:25:33Z")\
**Posts on this page:** 1\
**Showing post:** 55

<div class="post-metadata">

**Author:** ![goerz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerz/32/3269_2.png) [@goerz](https://discourse.julialang.org/u/goerz)\
**Post date:** [March 17, 2026, 4:43pm UTC](https://discourse.julialang.org/t/policies-around-registering-ai-created-packages-in-general/136228/55 "2026-03-17T16:43:31Z")

</div>

> [@Ronis\_BR](#):
>
> Registry is not curated. Besides very few checks, anyone can submit packages

That is not entirely true. There are both automatic and manual checks for packages that are submitted for registration, see, e.g., the discussion in

> [@When does it make sense to post a new package to the Julia repository?](https://discourse.julialang.org/t/when-does-it-make-sense-to-post-a-new-package-to-the-julia-repository/108701/4):
>
> To be registered, it should be at a “[minimum viable package](https://en.wikipedia.org/wiki/Minimum_viable_product)” stage (which is what a v0.1 release typically indicates). This means it should have some non-trivial functionality. It also should have some tests, and very importantly, some form of documentation. This doesn’t mean that a package needs a full Documenter-based website: for simple or early-stage packages, putting the documentation in the README if usually sufficient. It should include a description of what the purpose of the package is,…

> [@kahliburke](#):
>
> How many of the \>12k packages in the general registry currently compile on the latest and LTS versions of Julia

Hopefully many, as Julia Computing runs automated checks about this whenever releasing new versions.

> [@kahliburke](#):
>
> have tests that pass, over 50% unit test coverage, are well documented

There are minimum requirements for packages at registration time, and stricter requirements for 1.0 versions. I would be very open to making automated checks for new registrations stricter than they currently are. Running tests and checking for 50% unit test coverage in particular is something that’s been long on my mind. That’s a discussion to be had separately, though

> [@kahliburke](#):
>
> have been maintained (perhaps the bar being, have addressed any identified GitHub issue within the past 6 months)?

There is an expectation for registered packages that they continue to be maintained. If they become unmaintained: if nobody is submitting PRs and they continue to work, not problem. When PRs are submitted but not reviewed or merged, as registry maintainers we _actively_ facilitate new co-maintainers being added to old projects, in whatever form is appropriate. In the most extreme version of this, we have a form of “eminent domain” where an unmaintained package is forked to a new organization with new maintainers, and the the registry is modified to point to that new fork – even without the involvement of the original package author (if they were hit by the proverbial bus and have been unresponsive despite several months of communication attempts across different channels)

The bottom line is that the General registry is not free-for-all (as discussed in the intro to the [previous discussion about vibe-coded packages](https://discourse.julialang.org/t/should-general-have-a-guideline-or-rule-preventing-registration-of-vibe-coded-packages/133205)), but is a shared community resource

---

_[View the full topic](https://discourse.julialang.org/t/policies-around-registering-ai-created-packages-in-general/136228)._