From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.tangents Subject: Re: emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode) Date: Wed, 06 Sep 2023 10:04:26 +0000 Message-ID: <87zg1zsjmd.fsf@localhost> References: <87il9kksqz.fsf@dfreeman.email> <83zg2vav46.fsf@gnu.org> <87o7j99304.fsf@dfreeman.email> <97224c4f-fad4-ae01-46c1-5755d97d9a92@gutov.dev> <87fs3ztq38.fsf@localhost> <87cyz3qwba.fsf@posteo.net> <8734zztmiz.fsf@localhost> <87sf7zqs3l.fsf@yahoo.com> <87il8vs6e7.fsf@localhost> <87jztbqrc9.fsf@yahoo.com> <877cpbs5a0.fsf@localhost> <87fs3zqqgj.fsf@yahoo.com> <874jkfs4o0.fsf@localhost> <87y1hroz47.fsf@posteo.net> <87wmx7mzcf.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21227"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jschmidt4gnu@vodafonemail.de, emacs-tangents@gnu.org, manuel.uberti@inventati.org To: rms@gnu.org Original-X-From: emacs-tangents-bounces+get-emacs-tangents=m.gmane-mx.org@gnu.org Wed Sep 06 12:42:22 2023 Return-path: Envelope-to: get-emacs-tangents@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 1qdpzE-00057m-Kh for get-emacs-tangents@m.gmane-mx.org; Wed, 06 Sep 2023 12:42:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qdpyv-0005ed-Hc; Wed, 06 Sep 2023 06:41:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qdpNw-0003oc-1s for emacs-tangents@gnu.org; Wed, 06 Sep 2023 06:03:44 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qdpNq-0006xN-Eo for emacs-tangents@gnu.org; Wed, 06 Sep 2023 06:03:43 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 48292240028 for ; Wed, 6 Sep 2023 12:03:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1693994616; bh=MmQlbSjEDOsLsrL3UlIaggo+OD66ZuQrHtiRYAIp1/w=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=kamWvQXjuikEoA+WMoyhhwMmPZUdj5y+y0lD9J5cC6HLqv3tkfECsFXnteOrpc7Bs kkuH+63YwT1I+ZWuP79hhFjJLfIQQHqDg/HDDbTbX/eJ5S7y15QSXHOkYuaG9CqEkA G47eYX2SO9Cj4wW8fg5hSbYkLEwSBf9u/8vxzog63NZsOF/YyQJQKEDtSjuRvQmpHz 5RqLsgY3yWCyxixXUWdo9wF+upVoRHl2Wz7HdUPWFpzmmGTzJCS63oSiL7DaWlEmOv XgKgu5zhio1EA+Ob+WR/VFL12i38JZ5MDsY4xUzmOVGo48pYq46kg0NVNHlxGKag+x hIGnovJH4bIUg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RgdHW4cSKz9rxH; Wed, 6 Sep 2023 12:03:35 +0200 (CEST) In-Reply-To: Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 06 Sep 2023 06:41:55 -0400 X-BeenThere: emacs-tangents@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-tangents-bounces+get-emacs-tangents=m.gmane-mx.org@gnu.org Original-Sender: emacs-tangents-bounces+get-emacs-tangents=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.tangents:1050 Archived-At: Richard Stallman writes: > > 1. Maintainers often say "no" to certain things (like code refactoring > > that does not lead to any clear improvement) because they know from > > their extensive experience that some ideas are "non-starters". > > However, they do not elaborate much why one or another thing is not > > acceptable. > > > Not elaborating is actually perfectly understandable - it would be > > annoying to repeat the same thing many times and would also waste the > > maintainer's valuable time that could be spent for something more > > productive. > > I think I can understand why this feels painful -- but what concretely could > we ask the maintainers to do which would be better overall? I have two possibilities in mind: 1. For the common questions/misconceptions that keep appearing, there might be a dedicated FAQ answer that can be quickly linked to. For example, in Org mode we often point new contributors who did not follow our patch conventions to https://orgmode.org/worg/org-contribute.html#first-patch or quickly link to an explanation why ancient Emacs versions are not supported: https://orgmode.org/worg/org-maintenance.html#emacs-compatibility or explain our general maintenance principles in https://bzg.fr/en/the-software-maintainers-pledge/ 2. Do not treat all the users the same: - The users submitting bug report/email the very first time (or generally having just a handful of emails on the list) may be greeted with more welcoming style, with detailed explanations. Especially if such a user is proposing something that has to be rejected. - Users that do not seem to be familiar with specialized Elisp or Emacs terminology may require different reply style compared to devs, especially Elisp devs. > When you say "maintainers", do you mean the Emacs maintainers > (currently Eli, Stefan and I)? Or does it mean the people who develop > whichever file you're proposing a change to? I meant more than you three - whoever is replying to a proposal/suggestion with very confident tone implying good knowledge of the topic. Such people are usually Emacs maintainers, built-in Elisp library maintainers, and sometimes just random people who happen to sound knowledgeable. (I know that such random people often have nothing to do with Emacs team, but there is no easy way to distinguish them from real maintainers when reading long threads; for example see https://yhetil.org/emacs-devel/E1qXkGM-0005IS-PJ@fencepost.gnu.org/) > > 3. Sometimes, replies to certain feature request feel like a show > > stopper not because the feature itself is not acceptable, but because > > the specific implementation is not deemed good. > > Would it be halp if the people who respond make an effort to > distinguish between their comment about the the behavior tat could be > changed, and their comments about the specific method of implementing > that change? We might be able to get better at that, since I expect > everyone will agree it is good to do that if one can. It would indeed help. Another possibility is following the style often used in technical conferences: (1) Always acknowledge what is good about presentation/idea; (2) Go ahead with questions/critique. That first part is often very trivial - it will not directly lead to improving the presented work/idea, but it really helps to not sound like "I only have questions/critique about your work. Nothing else, nothing good.". -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at