Make the authors field optional

text/0000-deprecate-authors-field.md

@@ -0,0 +1,140 @@
+# RFC: Deprecate the authors field
+
+- Feature Name: `deprecate_authors_field`
+- Start Date: 2021-01-07
+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)
+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)
+
+# Summary
+[summary]: #summary
+
+This RFC proposes to deprecate the `package.authors` field of `Cargo.toml`.
+This also implies preventing Cargo from auto-filling it, allowing crates to be
+published to crates.io without the field being present, and avoiding displaying
+its contents on the crates.io and docs.rs UI.
+
+# Motivation
+[motivation]: #motivation
+
+The crates.io registry does not allow users to change the contents of already
+published versions: this is highly desirable to ensure working builds don't
+break in the future, but it also has the unfortunate side-effect of preventing
+people from updating the list of crate authors defined in `Cargo.toml`'s
+`package.authors` field.
+
+This is especially problematic when people change their name or want to remove
+their name from the Internet, and the crates.io team doesn't have any way to
+address that at the moment except for deleting the affected crates or versions
+altogether. We don't do that lightly, but there were a few cases where we were
+forced to do so.
+
+The contents of the field also tend to scale poorly as the size of a project
+grows, with projects either making the field useless by just stating "The
+$PROJECT developers" or only naming the original authors without mentioning
+other major contributors.
+
+# Guide-level explanation
+[guide-level-explanation]: #guide-level-explanation
+
+crates.io will allow publishing crates without the `package.authors` field, and
+it will stop showing the contents of the field in its UI (the current owners
+will still be shown). docs.rs will also replace that data with the crate
+owners.
+
+`cargo init` will stop pre-populating the field when running the command, and
+it will not include the field at all in the default `Cargo.toml`. Crate authors
+will still be able to manually include the field before publishing if they so
+choose. Eventually Cargo will warn when publishing crates with the field set.
+
+Crates that currently rely on the field being present (for example by reading
+the `CARGO_PKG_AUTHORS` environment variable) will have to handle the field
+being missing (for example by switching from the `env!` macro to
+`option_env!`). Eventually they will have to provide a way to inline the
+information in the crate's source code, if the consumer of the crate desires to
+do so.
+
+# Reference-level explanation
+[reference-level-explanation]: #reference-level-explanation
+
+The implementation of this RFC spans multiple parts of the Rust project:
+
+## Cargo
+
+Cargo will stop fetching the current user's name and email address when running
+`cargo init`, and it will not include the field in the default template for
+`Cargo.toml`. Cargo will also treat the field as deprecated, eventually
+displaying a deprecation warning when someone tries to publish a crate with the
+field set.
+
+## crates.io
+
+crates.io will allow publishing versions without the field and with the field
+empty. The Web UI will remove the authors section, while retaining the current
+owners section.
+
+The API will continue returning the `authors` field in every endpoint which
+currently includes it, but the field will always be empty (even if the crate
+author manually adds data to it). The database dumps will also stop including
+the field.
+
+## docs.rs
+
+docs.rs will replace the authors with the current owners in its UI.
+
+# Drawbacks
+[drawbacks]: #drawbacks
+
+Cargo currently provides author information to the crate via
+`CARGO_PKG_AUTHORS`, and some crates (such as `clap`) use this information.
+Deprecating the authors field will require crates currently using it to change,
+such as by inlining the author data.
+
+This RFC will make it harder for third-party tools to query the author
+information of crates published to crates.io.
+
+By design, this RFC removes the ability to know historical crate authors. In
+some cases, crate authors may have wanted that information preserved. After
+this RFC, crate authors who want to display historical authors who are not
+current crate owners will have to present that information in some other way.
+
+# Rationale and alternatives
+[rationale-and-alternatives]: #rationale-and-alternatives
+
+This RFC reduces the problems related to changing the names in the authors
+field significantly, as people will now have to explicitly want to add that
+data instead of it being there by default.
+
+We could do nothing, but that would increase the support load of the crates.io
+team and would result in more crates being removed from the registry due to
+this issue.
+
+# Prior art
+[prior-art]: #prior-art
+
+* **JavaScript:** `package.json` has an optional `authors` field, but it's not
+  required and the interactive `npm init` command does not prepopulate the
+  field, leaving it empty by default. The npm Web UI does not show the contents
+  of the field.
+* **Python:** `setup.py` does not require the `authors` field. The PyPI Web UI
+  shows its contents when present.
+* **Ruby:** `*.gemspec` requires the `authors` field, and the RubyGems Web UI
+  shows its contents.
+* **PHP:** `composer.json` has an optional `authors` field. While it's not
+  required, the interactive `composer init` command allows you to choose
+  whether to pre-populate it based on the current environment or skip it. The
+  Packagist Web UI does not show the contents of the field.
+
+# Unresolved questions
+[unresolved-questions]: #unresolved-questions
+
+* What should we do about the metadata in already published crates?
+
+# Future possibilities
+[future-possibilities]: #future-possibilities
+
+The `package.authors` field could be removed in a future edition.
+
+A future RFC could propose separating metadata fields that could benefit from
+being mutable out of `Cargo.toml` and the crate tarball, allowing them to be
+changed without having to publish a new version. Such RFC should also propose a
+standardized way to update and distribute the extracted metadata.