doc/roadmap-2021.md

   1 # Roadmap 2021
   2
   3 # Summary
   4
   5 This Roadmap lays out the plans for Clippy in 2021:
   6
   7 - Improving usability and reliability
   8 - Improving experience of contributors and maintainers
   9 - Develop and specify processes
  10
  11 Members of the Clippy team will be assigned tasks from one or more of these
  12 topics. The team member is then responsible to complete the assigned tasks. This
  13 can either be done by implementing them or by providing mentorship to interested
  14 contributors.
  15
  16 # Motivation
  17
  18 With the ongoing growth of the Rust language and with that of the whole
  19 ecosystem, also Clippy gets more and more users and contributors. This is good
  20 for the project, but also brings challenges along. Some of these challenges are:
  21
  22 - More issues about reliability or usability are popping up
  23 - Traffic is hard to handle for a small team
  24 - Bigger projects don't get completed due to the lack of processes and/or time
  25   of the team members
  26
  27 Additionally, according to the [Rust Roadmap 2021], clear processes should be
  28 defined by every team and unified across teams. This Roadmap is the first step
  29 towards this.
  30
  31 [Rust Roadmap 2021]: https://github.com/rust-lang/rfcs/pull/3037
  32
  33 # Explanation
  34
  35 This section will explain the things that should be done in 2021. It is
  36 important to note, that this document focuses on the "What?", not the "How?".
  37 The later will be addressed in follow-up tracking issue, with an assigned team
  38 member.
  39
  40 The following is split up in two major sections. The first section covers the
  41 user facing plans, the second section the internal plans.
  42
  43 ## User Facing
  44
  45 Clippy should be as pleasant to use and configure as possible. This section
  46 covers plans that should be implemented to improve the situation of Clippy in
  47 this regard.
  48
  49 ### Usability
  50
  51 In the following, plans to improve the usability are covered.
  52
  53 #### No Output After `cargo check`
  54
  55 Currently when `cargo clippy` is run after `cargo check`, it does not produce
  56 any output. This is especially problematic since `rust-analyzer` is on the rise
  57 and it uses `cargo check` for checking code. A fix is already implemented, but
  58 it still has to be pushed over the finish line. This also includes the
  59 stabilization of the `cargo clippy --fix` command or the support of multi-span
  60 suggestions in `rustfix`.
  61
  62 - [#4612](https://github.com/rust-lang/rust-clippy/issues/4612)
  63
  64 #### `lints.toml` Configuration
  65
  66 This is something that comes up every now and then: a reusable configuration
  67 file, where lint levels can be defined. Discussions about this often lead to
  68 nothing specific or to "we need an RFC for this". And this is exactly what needs
  69 to be done. Get together with the cargo team and write an RFC and implement such
  70 a configuration file somehow and somewhere.
  71
  72 - [#3164](https://github.com/rust-lang/rust-clippy/issues/3164)
  73 - [cargo#5034](https://github.com/rust-lang/cargo/issues/5034)
  74 - [IRLO](https://internals.rust-lang.org/t/proposal-cargo-lint-configuration/9135/8)
  75
  76 #### Lint Groups
  77
  78 There are more and more issues about managing lints in Clippy popping up. Lints
  79 are hard to implement with a guarantee of no/few false positives (FPs). One way
  80 to address this might be to introduce more lint groups to give users the ability
  81 to better manage lints, or improve the process of classifying lints, so that
  82 disabling lints due to FPs becomes rare. It is important to note, that Clippy
  83 lints are less conservative than `rustc` lints, which won't change in the
  84 future.
  85
  86 - [#5537](https://github.com/rust-lang/rust-clippy/issues/5537)
  87 - [#6366](https://github.com/rust-lang/rust-clippy/issues/6366)
  88
  89 ### Reliability
  90
  91 In the following, plans to improve the reliability are covered.
  92
  93 #### False Positive Rate
  94
  95 In the worst case, new lints are only available in nightly for 2 weeks, before
  96 hitting beta and ultimately stable. This and the fact that fewer people use
  97 nightly Rust nowadays makes it more probable that a lint with many FPs hits
  98 stable. This leads to annoyed users, that will disable these new lints in the
  99 best case and to more annoyed users, that will stop using Clippy in the worst.
 100 A process should be developed and implemented to prevent this from happening.
 101
 102 - [#6429](https://github.com/rust-lang/rust-clippy/issues/6429)
 103
 104 ## Internal
 105
 106 (The end of) 2020 has shown, that Clippy has to think about the available
 107 resources, especially regarding management and maintenance of the project. This
 108 section address issues affecting team members and contributors.
 109
 110 ### Management
 111
 112 In 2020 Clippy achieved over 1000 open issues with regularly between 25-35 open
 113 PRs. This is simultaneously a win and a loss. More issues and PRs means more
 114 people are interested in Clippy and in contributing to it. On the other hand, it
 115 means for team members more work and for contributors longer wait times for
 116 reviews. The following will describe plans how to improve the situation for both
 117 team members and contributors.
 118
 119 #### Clear Expectations for Team Members
 120
 121 According to the [Rust Roadmap 2021], a document specifying what it means to be
 122 a member of the team should be produced. This should not put more pressure on
 123 the team members, but rather help them and interested folks to know what the
 124 expectations are. With this it should also be easier to recruit new team members
 125 and may encourage people to get in touch, if they're interested to join.
 126
 127 #### Scaling up the Team
 128
 129 More people means less work for each individual. Together with the document
 130 about expectations for team members, a document defining the process of how to
 131 join the team should be produced. This can also increase the stability of the
 132 team, in case of current members dropping out (temporarily). There can also be
 133 different roles in the team, like people triaging vs. people reviewing.
 134
 135 #### Regular Meetings
 136
 137 Other teams have regular meetings. Clippy is big enough that it might be worth
 138 to also do them. Especially if more people join the team, this can be important
 139 for sync-ups. Besides the asynchronous communication, that works well for
 140 working on separate lints, a meeting adds a synchronous alternative at a known
 141 time. This is especially helpful if there are bigger things that need to be
 142 discussed (like the projects in this roadmap). For starters bi-weekly meetings
 143 before Rust syncs might make sense.
 144
 145 #### Triaging
 146
 147 To get a handle on the influx of open issues, a process for triaging issues and
 148 PRs should be developed. Officially, Clippy follows the Rust triage process, but
 149 currently no one enforces it. This can be improved by sharing triage teams
 150 across projects or by implementing dashboards / tools which simplify triaging.
 151
 152 ### Development
 153
 154 Improving the developer and contributor experience is something the Clippy team
 155 works on regularly. Though, some things might need special attention and
 156 planing. These topics are listed in the following.
 157
 158 #### Process for New and Existing Lints
 159
 160 As already mentioned above, classifying new lints gets quite hard, because the
 161 probability of a buggy lint getting into stable is quite high. A process should
 162 be implemented on how to classify lints. In addition, a test system should be
 163 developed to find out which lints are currently problematic in real world code
 164 to fix or disable them.
 165
 166 - [#6429 (comment)](https://github.com/rust-lang/rust-clippy/issues/6429#issuecomment-741056379)
 167 - [#6429 (comment)](https://github.com/rust-lang/rust-clippy/issues/6429#issuecomment-741153345)
 168
 169 #### Processes
 170
 171 Related to the point before, a process for suggesting and discussing major
 172 changes should be implemented. It's also not clearly defined when a lint should
 173 be enabled or disabled by default. This can also be improved by the test system
 174 mentioned above.
 175
 176 #### Dev-Tools
 177
 178 There's already `cargo dev` which makes Clippy development easier and more
 179 pleasant. This can still be expanded, so that it covers more areas of the
 180 development process.
 181
 182 - [#5394](https://github.com/rust-lang/rust-clippy/issues/5394)
 183
 184 #### Contributor Guide
 185
 186 Similar to a Clippy Book, which describes how to use Clippy, a book about how to
 187 contribute to Clippy might be helpful for new and existing contributors. There's
 188 already the `doc` directory in the Clippy repo, this can be turned into a
 189 `mdbook`.
 190
 191 #### `rustc` integration
 192
 193 Recently Clippy was integrated with `git subtree` into the `rust-lang/rust`
 194 repository. This made syncing between the two repositories easier. A
 195 `#[non_exhaustive]` list of things that still can be improved is:
 196
 197 1. Use the same `rustfmt` version and configuration as `rustc`.
 198 2. Make `cargo dev` work in the Rust repo, just as it works in the Clippy repo.
 199    E.g. `cargo dev bless` or `cargo dev update_lints`. And even add more things
 200    to it that might be useful for the Rust repo, e.g. `cargo dev deprecate`.
 201 3. Easier sync process. The `subtree` situation is not ideal.
 202
 203 ## Prioritization
 204
 205 The most pressing issues for users of Clippy are of course the user facing
 206 issues. So there should be a priority on those issues, but without losing track
 207 of the internal issues listed in this document.
 208
 209 Getting the FP rate of warn/deny-by-default lints under control should have the
 210 highest priority. Other user facing issues should also get a high priority, but
 211 shouldn't be in the way of addressing internal issues.
 212
 213 To better manage the upcoming projects, the basic internal processes, like
 214 meetings, tracking issues and documentation, should be established as soon as
 215 possible. They might even be necessary to properly manage the projects,
 216 regarding the user facing issues.
 217
 218 # Prior Art
 219
 220 ## Rust Roadmap
 221
 222 Rust's roadmap process was established by [RFC 1728] in 2016. Since then every
 223 year a roadmap was published, that defined the bigger plans for the coming
 224 years. This years roadmap can be found [here][Rust Roadmap 2021].
 225
 226 [RFC 1728]: https://rust-lang.github.io/rfcs/1728-north-star.html
 227
 228 # Drawbacks
 229
 230 ## Big Roadmap
 231
 232 This roadmap is pretty big and not all items listed in this document might be
 233 addressed during 2021. Because this is the first roadmap for Clippy, having open
 234 tasks at the end of 2021 is fine, but they should be revisited in the 2022
 235 roadmap.