Incubating features: try a style first, decide later

[abashev]

Why

Many proposals here are a matter of taste: keep @Mock on the field's line, keep a Map.of key next to its value,
group Mutiny calls into phrases. Each one has people who want it and people who would rather not have it. Today there
are only two answers: change the output for everyone, or say no. Upstream projects mostly say no, and good ideas get
closed unmerged.

The idea

A proposed style change can ship as an incubating feature. It is part of the regular release, off by default, and
switched on by name by those who want to try it. Nobody's output changes unless they opt in.

Lifecycle

1. Proposal. An issue or a discussion shows the change with a before/after example.
2. Incubating. Maintainers accept it as incubating, and it ships in the next release. Each feature gets its own
   discussion thread for feedback.
3. Decision, on a deadline. After a fixed period, say six months, the feature is either promoted, becoming
   the default in the next minor version, or removed. No feature stays incubating forever: the formatter is not
   meant to be a box of personal preferences, and incubation should not become a back door to one.

How we decide

Votes alone are a weak signal for a project of our size, so we would look at several things:

• votes and comments in the feature's discussion;
• bugs reported against the feature while it was incubating;
• real usage: an opt-in setting in the IntelliJ plugin that anonymously reports which incubating features are
  switched on. Nothing is sent unless you turn it on;
• the final call is made by the maintainers, with the reasons written down in the discussion.

Open questions

• How should votes be weighed? One option is to weight each vote by the GitHub stars of the voter's account, so
  that the authors of widely used projects carry more weight. But how do maintainers count then: do they vote like
  everyone else, or do they only make the final call? Another option is to count the projects that actually enable
  the feature rather than the people who vote for it.
• How long should incubation last? Is six months right, or should it be tied to releases?
• Is opt-in usage reporting acceptable to you at all?

First candidates

• Option to keep a single marker annotation on the field's line #159 Keep a single marker annotation on the field's line
• Keep an author-written argument table even when later columns are not of one kind #158 Keep an author-written argument table
• Bring over upstream PR #1731: keep a map factory's key and value on one line #31 Keep a map factory's key and value on one line

What do you think? Would you try incubating features on your code base?