Child Thread: Survey of organizational ownership designs for Cargo and Crates.io

For https://lib.rs I wanted to figure out grouping of packages like "official Rust package", or "tokio crate", or sort packages like serde-* into officially belonging to a project vs 3rd-party crates that are for the project.

Something explicit is definitely needed. Heuristics aren't sufficient - there are soo many edge cases.

• there can be some primary package foo owned by owners A, B, and C, and packages foo-something owned by A only, or B+C, or A and other owners. Figuring out who is the real owner of the "namespace" is very tricky. Sometimes foo and foo-quuz may have the same owner, but the owner considers foo-quuz a side project or a reserved name, not really belonging to the foo project. Some crates have a GitHub org account, but not added to all of the relevant packages. Sometimes the non-user account is just a bot that's not a real project owner.

• even crates sharing a monorepo don't always belong to the same project! Even after verifying the crates really exist in the repository from the URL in the package, and aren't forks or fakes, they can turn out to be helper utilities (for CI, precompiled data) or crates maintained for the project by the project members, but intended to be usable outside of it (like a CLI arguments parser).

• "Rust official" also doesn't exist. There are many members of the Rust org who publish their own packages, not as Rust representatives. There's huge legacy of alexcrichton's packages. There are packages technically owned by rust-lang-owner, which greatly vary in their importance (from key crates to forgotten experiments), release process, de-facto owners/maintainers.