From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Re: Confused by y-or-n-p Date: Mon, 4 Jan 2021 08:54:37 +0100 Message-ID: References: <834kkcr1eo.fsf@gnu.org> <83bleinmse.fsf@gnu.org> <56435592-d2d0-5fb6-977f-01e1931da835@gmx.at> <87k0t38g1z.fsf@mail.linkov.net> <83czyvkts6.fsf@gnu.org> <87bleetirr.fsf@mail.linkov.net> <87y2hhri3n.fsf@mail.linkov.net> <83pn2tkfg8.fsf@gnu.org> <871rf7ippu.fsf@mail.linkov.net> <83a6trg6mc.fsf@gnu.org> <87im8f951f.fsf@gnus.org> <83lfdacapo.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19846"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, rudalics@gmx.at, Eli Zaretskii , juri@linkov.net, larsi@gnus.org, drew.adams@oracle.com To: Stefan Monnier , Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 04 08:56:11 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kwKip-00053P-Gc for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 08:56:11 +0100 Original-Received: from localhost ([::1]:47888 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwKio-00061Y-36 for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 02:56:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51506) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwKhN-0005Th-Ep for emacs-devel@gnu.org; Mon, 04 Jan 2021 02:54:41 -0500 Original-Received: from mail-pl1-x62c.google.com ([2607:f8b0:4864:20::62c]:38533) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kwKhL-00068E-SV; Mon, 04 Jan 2021 02:54:41 -0500 Original-Received: by mail-pl1-x62c.google.com with SMTP id 4so14121691plk.5; Sun, 03 Jan 2021 23:54:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=ZcLIgtgjarok61x2t4sGcm+xHXPeIg/8GxwzAYOyhkU=; b=js0sGNNBEo66Ijv2VsS4TipWab7MnIe7VIWAMAFaenOe156O62e5PrQAO9MJFyZ9BA HqNgC0SdnVe4AIJ1gkR7HfJ6DdSTHmApirheVvHEhMcnzxw3C2c5hLuMpS/Mu0In98CN aq65ZVSVg8LI9ltPwkG92vyjANWQO5fnb4ILyDrVAUSHSLQZwwv9EgFnAjXCvh3d/n6q F2iP+tbmsy2h38fO6zKoQBWpITqqR0j8Or5VlpdG3eGz5tZTbRXXcrzyVZaOymegRHwO tBf+F4Q58AbDg4GwNSvJM/ZEa44vPp/teg9pGtmj0jVGdAhAVhvsdSchhxTNBBLokQQS tYHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=ZcLIgtgjarok61x2t4sGcm+xHXPeIg/8GxwzAYOyhkU=; b=bz9A0U1z3IVRdMyVIk9+biT+W13qt/zjkswWwoTqZOa16P5ascPVJfEnQpQN1kM6yS PiIZ1OSJfb6tjJFvUPS4NZoqp0DZqNLL+xjzLjfJrSQXRj8uOOFcVZnqjACc/pXaRP6E RFR06oVjCwNR1mnGO/P8GJTwncmhFpSbWQyKPkug+mOY1o2lBTljPgqCsZ5R5kFQUpo+ jSGnz6j/AtMPOt1IxGGGiY4bHkQTiIP5QQpR+pzJ5XRPxNhqoA2Gq5YG3ndlp/p4Oz3Z dmYkCVOqo7uW71RgHoId6VT1H+6ejFzQR70BoOQZP8fRAYdFsyLZGqw0uGTvY7i/OOX2 paqA== X-Gm-Message-State: AOAM532/Dm2QiXtX2jhpyu+pg4fFnhWD7dSk16Dw2OQNmXqnpa/u8E4e yR+DPCU5juRMIJXO4ja8+xYkPmG16LbyMeQv5jU= X-Google-Smtp-Source: ABdhPJx7A4zYUQjF6mTxGGvVx5p0eLZ/LnQuoWp2PVOJohPue7hG2sq8IS8/MX7a/Zut2qF7chelNSILm2ij9WRfmL4= X-Received: by 2002:a17:902:9309:b029:db:c725:d19c with SMTP id bc9-20020a1709029309b02900dbc725d19cmr50362474plb.39.1609746877895; Sun, 03 Jan 2021 23:54:37 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 4 Jan 2021 08:54:37 +0100 In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::62c; envelope-from=stefankangas@gmail.com; helo=mail-pl1-x62c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:262399 Archived-At: Stefan Monnier 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.)