From 7bade2f792d14060e5f0f2d337fc0cd30dc04d6f Mon Sep 17 00:00:00 2001 From: flip1995 Date: Tue, 15 Dec 2020 21:28:12 +0100 Subject: [PATCH] Add Roadmap for 2021 --- doc/roadmap-2021.md | 227 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 227 insertions(+) create mode 100644 doc/roadmap-2021.md diff --git a/doc/roadmap-2021.md b/doc/roadmap-2021.md new file mode 100644 index 000000000000..7e2b73aa4550 --- /dev/null +++ b/doc/roadmap-2021.md @@ -0,0 +1,227 @@ +# Roadmap 2021 + +## Summary + +This Roadmap lays out the plans for Clippy in 2021: + +- Improving usability and reliability +- Improving experience of Contributors and Maintainers +- Develop and specify processes + +Members of the Clippy team will be assigned tasks from one or more of these +topics. The team member is then responsible to complete the assigned tasks. This +can either be done by implementing it or by providing mentorship to interested +contributors. + +## Motivation + +With the ongoing growth of the Rust language and with that the whole ecosystem, +also Clippy gets more and more users and contributors. This is good for the +project, but also brings challenges along. Some of these challenges are: + +- More issues about reliability or usability are popping up +- Traffic is hard to handle for a small team +- Bigger projects don't get completed due to the lack of processes and/or time + of the team members + +Additionally, according to the [Rust Roadmap 2021], clear processes should be +defined by every team and unified across teams. This Roadmap is the first step +for doing this. + +[Rust Roadmap 2021]: https://github.com/rust-lang/rfcs/pull/TODO + +## Explanation + +This section will explain the things that should be done in 2021. It is +important to note, that this document focuses on the "What?", not the "How?". +The later will be addressed in follow-up tracking issue, with a assigned team +member. + +The following is split up in two major sections. The first section covers the +user facing plans, the second section the internal plans. + +### User Facing + +Clippy should be as pleasant to use and configure as possible. This section +covers plans that should be implemented to improve the situation of Clippy in +this regard. + +#### Usability + +In the following, plans to improve the usability are covered. + +##### No Output After `cargo check` + +Currently when `clippy` is run after `cargo check`, it does not produce any +output. This is especially problematic since `rust-analyzer` is on the rise and +it uses `cargo check` for checking code. A fix is already implemented, but it +still has to be pushed over the finish line. This also includes the +stabilization of the `cargo clippy --fix` command or the support of multi-span +suggestions in `rustfix`. + +[#4612](https://github.com/rust-lang/rust-clippy/issues/4612) + +##### `lints.toml` Configuration + +This is something that comes up every now and then: a reusable configuration +file, where lint levels can be defined. Discussions about this often lead to +nothing specific or to "we need an RFC for this". And this is exactly what needs +to be done. Get together with the cargo team and write an RFC and implement such +a configuration file somehow and somewhere. + +[#3164](https://github.com/rust-lang/rust-clippy/issues/3164) +[cargo#5034](https://github.com/rust-lang/cargo/issues/5034) +[IRLO](https://internals.rust-lang.org/t/proposal-cargo-lint-configuration/9135/8) + +##### Lint Groups + +The are more and more issues about managing lints in Clippy. Lints are hard to +implement with a guarantee of no/few false positives (FPs). One way to address +this might be to introduce more lint groups to give users the ability to better +manage lints, or improve the process of classifying lints, so that disabling +lints due to FPs becomes rare. It is important to note, that Clippy lints are +less conservative than `rustc` lints, which won't change in the future. + +[#5537](https://github.com/rust-lang/rust-clippy/issues/5537) +[#6366](https://github.com/rust-lang/rust-clippy/issues/6366) + +#### Reliability + +In the following, plans to improve the usability are covered. + +##### False Positive Rate + +In the worst case, new lints are only available in nightly for 2 weeks, before +hitting beta and ultimately stable. This and the fact that fewer people use +nightly Rust nowadays makes it more more probable that a lint with many FPs hits +stable. This leads to annoyed users, that will disable these new lints in the +best case and to more annoyed users, that will stop using Clippy in the worst. +A process should be developed and implemented to prevent this from happening. + +[#6429](https://github.com/rust-lang/rust-clippy/issues/6429) + +### Internal + +(The end of) 2020 has shown, that Clippy has to think about the available +resources, especially regarding management and maintenance of the project. This +section address issues affecting team members and contributors. + +#### Management + +In 2020 Clippy achieved over 1000 open issues with regularly between 25-35 open +PRs. This is simultaneously a win and a loss. More issues and PRs means more +people are interested in Clippy and in contributing to it. On the other hand, it +means for team members more work and for contributors longer wait times for +reviews. The following will describe plans how to improve the situation for +both team members and contributors. + +##### Clear Expectations for Team Members + +According to the [Rust Roadmap 2021], a document specifying what it means to be +a member of the team should be produced. This should not put more pressure on +the team members, but rather help them and interested folks to know what our +expectations are. With this it should also be easier to recruit new team members +and may encourage people to get in touch, when they're interested to join. + +##### Scaling up the Team + +More people means less work for each individual. Together with the document +about expectations for team member, a document defining the process of how to +join the team should be produced. This can also increase the stability of the +team, in case of current members dropping out (temporarily). There can also be +different roles in the team, like people triaging vs. people reviewing. + +##### Regular Meetings + +Other teams have regular meetings. Clippy is big enough that it might be worth +to also do them. Especially if more people join the team, this can be important +for sync-ups. Besides the asynchronous communication, that works well for +working on separate lints, a meeting adds a synchronous alternative at a known +time. This is especially helpful if there are bigger things that need to be +discussed (like the projects in this roadmap). For starters bi-weekly meetings +before Rust syncs might mike sense. + +##### Triaging + +To get a handle on the influx in open issues, a process for triaging issues and +PRs should be developed. Officially Clippy follows the Rust triage process, but +currently no one enforces it. This can be improved by sharing triage teams +across projects or by implementing dashboards / tools which simplify triaging. + +#### Development + +Improving the developer and contributor experience is something the Clippy team +worked on regularly before. Some things might need special attention and +planing. These topics are listed in the following. + +##### Process for New and Existing Lints + +As already mentioned above, classifying new lints gets quite hard, because the +probability of a buggy lint getting into stable is quite high. A process should +be implemented on how to classify lints. In addition, a test system should be +developed to find out which lints are currently problematic in real world code +to fix or disable them. + +[#6429 (comment)](https://github.com/rust-lang/rust-clippy/issues/6429#issuecomment-741056379) +[#6429 (comment)](https://github.com/rust-lang/rust-clippy/issues/6429#issuecomment-741153345) + +##### Processes + +Related to the point before, a process for suggesting and discussing major +changes should be implemented. It's also not clearly defined when a lint should +be enabled or disabled by default. This can also be improved by the test system +mentioned above. + +##### Dev-Tools + +There's already `cargo dev` which makes Clippy development easier and more +pleasant. This can still be expanded, so that it covers more areas of the +development process. + +[#5394](https://github.com/rust-lang/rust-clippy/issues/5394) + +##### Contributor Guide + +Similar to a Clippy Book, which describes how to use Clippy, a book about how to +contribute to Clippy might be helpful for new and existing contributors. There's +already the `doc` directory in the Clippy repo, this can be turned into a +`mdbook`. + +##### `rustc` integration + +Recently Clippy was integrated as a `git subtree` into the `rust-lang/rust` +repository. This made syncing between the two repositories easier. A +`#[non_exhaustive]` list of things that still can be improved is: + +1. Use the same `rustfmt` incl. configuration as `rustc` +2. Make `cargo dev` work in the Rust repo, just as it works in the Clippy repo. + E.g. `cargo dev bless` or `cargo dev update_lints`. And even add more things + to it that might be useful for the Rust repo, e.g. `cargo dev deprecate`. +3. Easier sync process. The `subtree` situation is not ideal. + +## Prior Art + +### Rust Roadmap + +Rust's roadmap process was established by [RFC 1728] in 2016. Since then every +year a roadmap was published, that defined the bigger plans for the coming +years. This years roadmap can be found [here][Rust Roadmap 2021]. + +[RFC 1728]: https://rust-lang.github.io/rfcs/1728-north-star.html + +## Drawbacks + +### Big Roadmap + +This roadmap is pretty big and not all items listed in this document might be +addressed during 2021. Because this is the first roadmap for Clippy, having open +tasks at the end of 2021 is fine, but they should be revisited in the 2022 +roadmap. + +## Unresolved Questions + +### Prioritization + +This document is not in the order from highest to lowest priority, but grouped +into tasks that address the same broader topic. Prioritizing these tasks might +help to get them completed.