Re: Confused by y-or-n-p

[Stefan Kangas <stefankangas@gmail.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I am proposing a systematic way to make them less likely, by helping
>> people take notice that a UI change is being proposed, so they can
>> object quickly.
>
> In most cases, the reaction to UI changes is to complain about the
> change because it's ... different.  That makes for very poor arguments,
> *especially* when the change is discussed without people having actually
> tried it out for a while to see how it plays out in practice after the
> initial "bump".
>
> So, IMO always discussing such changes before implementing the change
> may be systematic but it is definitely not the best solution.

I agree completely.

To my mind, people running the bleeding edge (i.e. master) also
implicitly agree to test out new feature changes before they are
released.  So here's a suggestion: perhaps we should think about
sometimes carrying out time-boxed experiments on the master branch in
controversial cases.  For example: we add this keybinding now, to be
revisited in 14/21/30 days and then a final discussion is taken to keep
or revert it once people have gotten some experience with it.

I think this could work better than encouraging people to apply patches
or use a branch, since the people opposing them are less likely to do
so.  (And anyone who *really* don't want to participate can of course
still just revert that commit locally and carry on as before until the
experiment is over.)

This should be in the interest also of opponents of the change.  They
now have a very strong argument against discussing it further: "we tried
it on master and it was very unpopular so please don't beat this dead
horse".

(Of course, this would require people to also keep an open mind and a
willingness to change, or it will just be automatically shot down in the
next round of discussions.  Not sure what, if anything, can be done
about that.)