Take `authors` seriously

[savq]

In a recent Zulip discussion some package maintainers and users showed concern about the difficulty of determining the maintainance state of a package. This issue aims to direct some of the comments in a more actionable direction.

Project files can include an authors field with a list of authors' names and contact information. However, this field is optional, and in practice it doesn't seem to be used in much of the ecosystem. (I could be wrong, so I'd love to know if there's a programmatic way to determine how many packages in the entire general registry include this field.)

Providing more ways to interact with the authors field would help improve health of the ecosystem, since it'd make clear

1. who maintains a package, and by extension
2. the bus factor of a package, and
3. whether a package is maintained at all

Two concrete ideas to improve the current situation are:

• [x] When running ]generate, prompt the user to fill authors. To make this easier, default values based on git-config's user.name and user.email could be provided. Pkg already does this. I missed it the last time I checked src/generate.jl
• [ ] When running ]add or ]update, a flag could be used to warn about dependencies without an authors field.

Less concretely, at some point Pkg.jl could warn the package author(s) that they haven't set this field for their package (maybe during instantiate?).

That'd make it easier for new packages to include this data, and it'd make it easier for users to know whether their dependencies have maintainers. Then they could open an issue/PR to add authors, so the number of packages with the field would grow quickly.

Ideally, packages should not be included in the general registry without the authors field, but that is another discussion.

See also https://github.com/JuliaLang/Pkg.jl/issues/3705

[KristofferC]

However, this field is optional, and in practice it doesn't seem to be used in much of the ecosystem

Out of curiosity, do you have some concrete stats on this?

Also, ref https://github.com/JuliaLang/Pkg.jl/pull/3710.

[savq]

No concrete stats. I tried extracting my local General.tar.gz, but the Project.toml files there don't include that metadata.

But looking at the most popular packages, I see the following don't include authors:

• https://github.com/FluxML/Flux.jl/blob/master/Project.toml
• https://github.com/JuliaLang/IJulia.jl/blob/master/Project.toml
• https://github.com/jump-dev/JuMP.jl/blob/master/Project.toml
• https://github.com/TuringLang/Turing.jl/blob/master/Project.toml
• https://github.com/JuliaData/DataFrames.jl/blob/main/Project.toml

Some of these have very clear contributors, but the point is that, since there's nothing to suggest authors should be added, the practice of doing it is not widespread. As a side-note, the only popular packages I saw with more than one author listed were the Makie packages.

The Zulip discussion also focused on some organizations like JuliaIO and JuliaStats. The latter lists as it's authors "JuliaStats", which honestly is not useful at all 😐

Personally, I've encountered the same problem with JuliaGraphics, which has some really neglected packages.

[savq]

Also, @juliohm mentioned that there's a difference between an author and maintainer.

Author suggests the original creator of the package, while maintainer suggests the person currently in charge of the package. Arguably what we care about are the maintainers. Maybe we should take advantage of the fact that authors isn't popular to deprecate the name and add maintainers 😅

As a point of reference, here's what the cargo book has to say about their authors:

The optional authors field lists in an array the people or organizations that are considered the “authors” of the package. The exact meaning is open to interpretation — it may list the original or primary authors, current maintainers, or owners of the package. An optional email address may be included within angled brackets at the end of each author entry.

[KristofferC]

So say for Flux, what author entry would you like and how would that concretely help you (in a way that looking at e.g. the recent commits would not)?

[savq]

Git history is a noisy channel. For example, most of the recent commits in Flux are just compat maintenance, dep bumping, etc. This doesn't necessarily reflect code ownership.

We're also assuming that I already want to contribute, but in general, no one justs sits to read the commit history of their transitive dependencies. However, if Pkg.jl tells me "btw, your package depends on another package without authors", then I'd go and have a look, check if the package is maintained, and so on.

[KristofferC]

Okay, what should the author field in Flux be then?

However, if Pkg.jl tells me "btw, your package depends on another package without authors", then I'd go and have a look, check if the package is maintained, and so on.

Everyone would add an to authors when the package is created to avoid the warning. Would that help anything in practice?

[KristofferC]

https://github.com/JuliaFolds2/Transducers.jl/blob/master/Project.toml#L3

Takafumi Arakaki has been AWOL for more than a year. What good did it do you over looking at the latest commits?

[KristofferC]

The only point for Pkg here seems to be:

When running ]add or ]update, a flag could be used to warn about dependencies without an authors field.

which I don't think is a good idea. There is nothing really actionable for a user based on this and the presence/absence of an author field. But perhaps auto merge in the registry could be disabled if there is no author information.