From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 6bzvF5PWgGCRbQEAgWs5BA (envelope-from ) for ; Thu, 22 Apr 2021 03:51:15 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id wWJ+EpPWgGBTMwAAbx9fmQ (envelope-from ) for ; Thu, 22 Apr 2021 01:51:15 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 9091D2403A for ; Thu, 22 Apr 2021 03:51:14 +0200 (CEST) Received: from localhost ([::1]:37582 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lZOUq-0006BD-Vz for larch@yhetil.org; Wed, 21 Apr 2021 21:51:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54594) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lZOTP-00068T-Gz for emacs-orgmode@gnu.org; Wed, 21 Apr 2021 21:49:43 -0400 Received: from mail-pj1-x102a.google.com ([2607:f8b0:4864:20::102a]:40650) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lZOTN-0007yv-J2 for emacs-orgmode@gnu.org; Wed, 21 Apr 2021 21:49:43 -0400 Received: by mail-pj1-x102a.google.com with SMTP id g1-20020a17090adac1b0290150d07f9402so95157pjx.5 for ; Wed, 21 Apr 2021 18:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:subject:date:in-reply-to:message-id :mime-version; bh=mnNqOwNnG7ybOTvWuqEyZ/rE/s4ekMQteZ2Hbtg/TCs=; b=YCuDMGxytHt8R8lhT2K3gjNMIZNOT/ZPMS+BScbZXgRGXMFP8dzQUtkNlo9IGniJ8k L9czZZ4OjAQ0qhQCWQ9j8bkmk1jpWhB9zMvdyJjqVu9d/8kVtrZslB7fsAxcimabFPGk A1P0fy6Nh8nEhklLs/MZtwBjr80QLbwBGGdW+aLHkrwdpFUciNqcp4+y7K/OfKHHSHT9 iynthLWUE3ABnZzljnqKAowmD2WXJn7cwnqZyWyf5KkqrGsCTJxEpivU89wN0qCpePay M4h1DRwFkJ14Md2mNsDcU975X/ZX6PmqRxv8IJYUuc1SIublJG8cvQ2/2Ezx9GZT0MkQ 8aSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:subject:date :in-reply-to:message-id:mime-version; bh=mnNqOwNnG7ybOTvWuqEyZ/rE/s4ekMQteZ2Hbtg/TCs=; b=Lv57q9JJgh9xOyKnjzoV+3CeJTONyS4fKzJX0Ao+K6uS+96f3mDF/QAYpGy7jABH3t XJY//9MnKtt6EmKBL+GiRft0/SWO64l8x2uxQvxSoXTYDj4iwXIluLO4jwO8ysYLMMnd xQr+KsHqOatGqhbrjcsaYwEstCPcFk52ICQZMCpKoif1mhsR6xcg2dC7srAN1mSz0tIs YQ88rdox4osExs0UaqIuTjE29LgbZZqTEU2TpvieyCVIYEef1qWDue0YYdaeKtwBjziI i6ZwokHmymVu+/V1OviypYlsKLDwP0pd+RwqHzRDmTPoJHapeh5ZIZdb3Eb2PqXR0t9X QPvg== X-Gm-Message-State: AOAM533IU8u650p5K7/1RLpp1l9Z+EJvESAgsJTMMTC2DWtuL32hNSgI wIalJRYUAmqUxI0itEtCTc4/zSh8x8U= X-Google-Smtp-Source: ABdhPJwi1xG3Qvs8E3ivlqE+jk0AOQXZKMFDrcUaA5b5y5Cvw5fexeRUvYpcK3b+OlQmD3HPZc+XSA== X-Received: by 2002:a17:902:7682:b029:eb:2900:ed69 with SMTP id m2-20020a1709027682b02900eb2900ed69mr1096418pll.53.1619056176758; Wed, 21 Apr 2021 18:49:36 -0700 (PDT) Received: from tim-desktop (106-69-106-150.dyn.iinet.net.au. [106.69.106.150]) by smtp.gmail.com with ESMTPSA id u24sm516766pga.78.2021.04.21.18.49.35 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Apr 2021 18:49:36 -0700 (PDT) References: <87pmyuyssi.fsf@gmail.com> <87eef4hs9o.fsf@gmail.com> <467d556f-f0fa-018f-99c6-54fb748ab451@gmx.at> <1c557c0e35e04440ba2dadfe57e5b590@VI1PR0102MB3327.eurprd01.prod.exchangelabs.com> <878s5bojie.fsf@ucl.ac.uk> <878s5bifrf.fsf@gmail.com> User-agent: mu4e 1.5.11; emacs 28.0.50 From: Tim Cross To: emacs-orgmode@gnu.org Subject: Re: Concerns about community contributor support Date: Thu, 22 Apr 2021 10:48:10 +1000 In-reply-to: Message-ID: <87eef3f5qs.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::102a; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x102a.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-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1619056275; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=mnNqOwNnG7ybOTvWuqEyZ/rE/s4ekMQteZ2Hbtg/TCs=; b=uj7KYUByTrHeMpzNEp8jVoKJuQM8SlOnCXO4WDu1aOdSw0qD3E6JvJOaNCkAFApUP43I2i z6rz3MIQmE0jM8d5Cva/7fQIW1G6UxFUCoXztarXq2OQLuTJek/E+ipUlz94UFIdwf9iOm WeOgeqo8cXrIKuOYcaH34HldiL/0HnRdFisTw5CDdzay3WvlPcM+HEaAW7NwUJn9CaFpXn Pe5QAdESbDx+I8s3cucpGad371xrWUTQrXSiDKCNP0CLAjdfjHS6DIgWWXbso1ZcxEQi6W 8iLbscDxrseKrC8MYI2CU5Ws1AYahGZRpTnim2WO3O0DgnRntEB8Xij066INGg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1619056275; a=rsa-sha256; cv=none; b=JaIQ5fmFz5fKq2dczxUjXwptRdwmSp3g3XKGdRPacjU6DHeOlhZ80DL59UuVxqMGIRovl4 kPC2CDIcxCIipLAsjHb5brBCgEQ/h9rT2Vq4Mh66z4uvR+Lz5tdKrh0x6QpzgIy14KlmSn l8sEIMxGSQn1OmNzEvz0gh9EAGvK1xTwFDoLzpKrfpHpIVD1jTpxLaHRavoD86bLNZvtoE kcfimbpi8ZN6r07YXq9BwoKyqZK9nH9V0NOK/r83r72pW6BD7wqRNhoQgYVdNF9+4DMIeK SF4Yh76UFEl/nM973u13WrgWV6BkBJRMs86Vd4spyrE7ZeOm7KTj4QML7XzF2Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=YCuDMGxy; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Spam-Score: -1.64 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=YCuDMGxy; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: 9091D2403A X-Spam-Score: -1.64 X-Migadu-Scanner: scn0.migadu.com X-TUID: aEYed7UVotQn ian martins writes: > On Wed, Apr 21, 2021 at 3:45 PM Tim Cross wrote: > > Responding to essentially just flag you have seen the patch message > really only adds noise and may even 'drown out' those responses which > add real 'value' to any discussion. I also doubt that asking people to > do this would actually result in any actual change of behaviour by > subscribers. > > Timothy said there were 25 patches without response and the list goes back six months, so we're only talking about 50 emails per year. That assumes there is a single 'owner' who accepts the responsibility to respond to every patch submitted. That isn't the situation with open source projects where people volunteer their time. Having someone respond to the author of a patch and provide some meaningful feedback would be great, but I don't see how that can happen in a project which is already stretched and with limited resources. There has already been multiple messages requesting additional help and for volunteers willing to put in the time needed to maintain parts of org mode. Adding to that workload isn't going to help. responses to patches really need to come from community members who are sufficiently interested in the patch to examine it or make comment on how useful they feel it would be. To some extent, if someone submits a patch and hears nothing, either they have failed to clearly explain what the patch does (and therefore did not tweak any interest) or it is a patch to introduce functionality which is of low interest to community participants. I think you can classify patches into 3 basic types - 1. Bug fixes. Patches which do not change functionality, but address bugs and performance bottlenecks in existing features. At present, this type of patch seems to get applied fairly quickly. 2. Patches which extend existing functionality. This type of patch requires significant consideration and evaluation. They can be time consuming to assess and a call needs to be made as to whether the additional complexity such enhancements add can justify the increased maintenance overhead such enhancements introduce. This is particularly challenging with org mode because org supports a diverse and sometimes complex range of workflows. Verifying an enhancement will not have adverse impact on some of these workflows is difficult and time consuming. Even apparently simple and straight-forward changes can have unexpected impact - consider for example the enhancement to support electric indent mode. This seemed fairly straight-forward and was a change which made org mode aligned with other Emacs modes and helps improve consistency withing Emacs across modes. However, it has had some adverse impact and caused some confusion because of how it interacts with existing org behaviour and configuration settings, such as with org indentation behaviour. 3. Patches which introduce new functionality. This type of patch also requires considerable resources to evaluate and adds to overall maintenance load. It is one thing to write an extension, but a completely different thing to maintain it over time. Even assessing the real demand for such extensions is challenging and time consuming and represents a significant demand on volunteers time. Asking volunteers to respond to patches of type 2 and 3 within some nominated time period is probably unreasonable. It also runs the danger of discouraging people from stepping up to volunteer to help maintain parts of org. This is why I think a better approach would be to provide more details and explanation on patch submission which can help set the expectations for the patch submitter and provide some guidance on what to do if they want to encourage/ask for feedback. This is also part of why I think patches of type 3 and possibly many type 2 patches should be initially released as separate 'add on' packages and made available via gitlab/github/melpa by the individual responsible for writing the patch. The author would then be able to see how useful/popular/desired their patch is, be able to ask for feedback and be able to get issue/bug reports to refine their work. This could be viewed as an 'incubator' like process. If such an enhancement/extension turns out to be very popular or demanded by the org community, it could then be migrated into either org core or the proposed org contrib package (by which time, it would likely be more mature and stable than it was when initially developed). It also has the advantage of not impacting existing org users who are not interested in the enhancement/extension. For an org user, little is more frustrating than an enhancement/extension which results in them having to either modify their workflow or update their often large repository of org documents. If we were to provide a detailed explanation on how to contribute bug fixes, enhancements and extensions on the worg site, contributors will know what is required, will be able to set their expectations in -line with how things work and have increased clarity regarding the structure of the org mode project etc. I would be willing to start drafting such a page if the community thought this would be worthwhile and be prepared to assist and assuming those responsible for maintenance agree. What I draft would be a starting point only and would require input to ensure it does represent what the community and maintainers believe is the right direction to take. -- Tim Cross