Add Roadmap for 2021

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.