Tags system for General registry ("Quality badges")

Community
1

This is a continuation of Should General have a guideline or rule preventing registration of vibe-coded packages? , as suggested there in the post #68 by ericphanson.

There appears to be consensus that the registration process should mostly stay in the current form, with small additional limitations. It however has been suggested to complement the current system by tags reflecting some specific aspects of a package, one of the aspects being “curation”, “quality” or similar.

The same had been actually suggested by me before (Please more bureaucracy on package registrations! - #11 by Eben60), and more or less rejected, but now, with attitudes toward the issue seemingly changed, I’m coming back to it.

I think several quality categories can be introduced, like bronze/silver/gold badges, but let’s start with the most basic.

I’d suggest that after a certain time (e.g. 6 month) upon the initial registration, the author/maintainer can apply for a badge. There generally would be three kinds of checks:

Relevant metrics which can probably be collected more or less automatically are e.g.:

  • CI set up?
  • Test coverage set up in CI?
  • Test coverage extent.
  • Exported and public functions documented?
  • Downloads / Stars / Downstream dependencies
  • Authors reputation (number of “quality packages” they have already created, commits to Julia and “quality packages”).
  • Maintainance (updates, fixing of open issues).

For packages showing high metrics on all scores (reputed author or organization, lot of downloads..), the badge can be awarded without an additional review by an expert.

The badge will be awarded for a limited period of time (e.g. 1 or 2 years), then maintainers can re-apply.

In the thread “Please more bureaucracy”, one of the main objections was the system was not waterproof and could be cheated. Well, sure any system can be cheated…

Now, before we start discussing the details, I’d suggest to first clarify the main issue: If there is really a desire to set up that kind of system. Which is related to another main question: Who? I.e.: Who is going to implement?

2 Likes
2

I also supports the idea of having a live counter of downloads of Julia and it packages. Suppose a new version of Julia or its packages is released then we can see or visualize that how many people(anonymous count only) have updated to that version. There should be a public count of download of each version.

3

Beware conflating the tyranny of the status quo with a deliberate choice to not do something.

There are many distinct points here, but on the most salient one — the “granting” of “badges” — there is literally nothing standing in the way of someone choosing to do this.

It’s quite straightforward to parse the registry and mirror its contents with extra data. It’s highly automatable! I’ve started doing a little of this in GeneralMetadata.jl — that started out as a personal repo before we moved it to that org.

The trickier bit would be embedding the “tags” or other metadata officially into the registry or Pkg itself, but that becomes clearer once there’s a consensus around the data. And the data become more obvious when they already exist in some form.

Personally, I think a qualitative gold/silver/bronze badge there would be out of scope for that particular repo, but what I’ve been doing there is open and highly replicable. And I also want that repo to be a community-driven project, which is precisely why it now lives in a community org… so I’m open to having my mind changed, too!

3 Likes
4

This suggests a “push, not pull” viewpoint, where the package authors / maintainers apply for some kind of badge. I’d rather have it the opposite way: The curation committee selects packages they want to be part of the curated subset, and then begs the author to agree to some compromise on package governance, or blessings for a friendly re-distribution / fork.

Examples of that dichotomy are keynote speakers vs ordinary plebs at many conferences (organizers reach out to well-known people they’d like to invite, vs people submit something to well-known conference), or debian packages vs app-store (users want xyz to be conveniently accessible in debian, and ideally someone spends the effort to make it happen, with or without cooperation of xyz vs software authors apply to be granted access to some distribution channel).

This obviously does not scale. That’s the point of it! It should not scale!

Debian is at ~70k packages, archlinux at ~15k (pacman -Sl extra | wc -l). Compare with push-style mavencentral, which got 2.5 M new registrations in 2025. There are lots of excellent software projects that are missing from “pull not push” registries, and that is totally OK and expected.

The goal is to have “stdlib light”, not “general but with more controls”.

Of course many people wear many hats, and projects co-maintained / written by people who help maintain the curated subset would naturally tend to end up in the curated “stdlib light” much more often. That’s not a bug, it’s a feature. The point would be “useful signal for users and upstream maintainers and ecosystem”, not “fair process”.

Regarding tags, I’m do not think they are enough? cc @ericphanson because you suggested tags could do the job.

Say, there is package xyz that gets added to “stdlib light”. Some users may install “xyz from stdlib-light”, others might install “xyz from source/author”. Ideally both are the same.

But then, imagine some unhappy event. Maybe there is a critical issue, but all maintainers with write-access are on vacation and cannot be reached.

Now the process for “stdlib light” should be that the curation committee can simply temporarily take over the package in the curated registry and address the issue, without any fair process; while there should be a much fairer and slower process for the same thing in the general registry.

There is a big difference whether users have chosen to trust the package author, and the general registry simply helps with distribution – or whether users have chosen to directly trust the curation committee.

Other canonical example: Julia on archlinux can be installed via distro or from upstream/source. Both are different things with different governance and philosophy regarding use of system libs vs vendoring, but both satisfy the dependency of julia. It is the user’s choice which to use. (yes, this is not ideal and probably causes quite a support load for julia-gpu, due to bugs specific to the archlinux-flavored julia)