From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id IFLzCObefGAqVQEAgWs5BA (envelope-from ) for ; Mon, 19 Apr 2021 03:37:42 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id mOm2A+befGAsUAAAbx9fmQ (envelope-from ) for ; Mon, 19 Apr 2021 01:37:42 +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 475741E683 for ; Mon, 19 Apr 2021 03:37:41 +0200 (CEST) Received: from localhost ([::1]:44592 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lYIr5-0005lu-D3 for larch@yhetil.org; Sun, 18 Apr 2021 21:37:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35564) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lYIqT-0005la-Ki for emacs-orgmode@gnu.org; Sun, 18 Apr 2021 21:37:01 -0400 Received: from mail-pg1-x535.google.com ([2607:f8b0:4864:20::535]:46876) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lYIqR-0000Fn-9n for emacs-orgmode@gnu.org; Sun, 18 Apr 2021 21:37:01 -0400 Received: by mail-pg1-x535.google.com with SMTP id 31so7659915pgn.13 for ; Sun, 18 Apr 2021 18:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version; bh=h18/pq+VvCFhzf0qezhDacm8QjobJ6TENMA2n0CtRnE=; b=TOxeNt5r3H1pzs/ybqIKV+lWSPUUKJExztCi9cHh04COX9nlNKwHRiIVSGYYJ69peQ T+IpTM7/MDDGU4ujOYW6xKz7QkWoHUCIKqM+gPscL3aeBIgqkA+BlgFMI+WTo+wVG8Qy lW4VUMas7pgmSgG2/8EJPKNEdjjTn8/RjBDi7rze9CA1fFYNYC47HI49dFX84YDqbMpg EyMjwIJx24C7K1LrCswGPqTN1jBXPugaWJJhpf11nVCnh10bgBf6Xw/xYwXPv1Nb/Lwy PBMoUMrZ6VRqnRxXtu1x+936Izy7piSTyjitJe1oPSx87IhIXTPE3JLpYw3I36W0yxQI Fo1A== 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:cc:subject:date :in-reply-to:message-id:mime-version; bh=h18/pq+VvCFhzf0qezhDacm8QjobJ6TENMA2n0CtRnE=; b=ZWOQ1QV1sStTWLcJby8xXsb6oGM8wa29NSKbunNmoYRKsjYg1SxAPSoxqg3rvDn/gh 47SWKvXKiIM1cfGlnh+Hq/KK2PrguWcyIsdCLcEnOj9M1fzScMqrKEGYdfCZChq0C21H LTjm6v9o9YgvUoFCk3+O28dcOfs9Z25V+PCWFZzOYrZcXtuqPjmnJqnijmpMlz0J8lKl XVL1anHrFTS0H67nY2rAAMZ0ymcOyuMuIZgOklLtSi/ThP5ikTU/GZFl81beUWbLe0Id 5qKymeQpa5nCeKRtZ8TxKqsgqOLo6drdc+WcUI07E4edZ7Ic7KaLalrBSuS1daIDKF78 N3HQ== X-Gm-Message-State: AOAM532R9o/75G6L3fJVBKeO1ZFxjtomE6WBcqsoIp+RRDEZ9lhkum6J HE+l2Gw8J7r+UR3Ce5C4daPNPDa4foI= X-Google-Smtp-Source: ABdhPJx9m7rMXPvj1sy080gJQd6lfYrcnLLzZrdqX2obdfpkVW229mRp+qQ0ZDOiztXlwl3bQlC0zw== X-Received: by 2002:a65:4082:: with SMTP id t2mr9553549pgp.396.1618796217305; Sun, 18 Apr 2021 18:36:57 -0700 (PDT) Received: from tim-desktop (220-235-1-83.dyn.iinet.net.au. [220.235.1.83]) by smtp.gmail.com with ESMTPSA id gw19sm12694533pjb.4.2021.04.18.18.36.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 18 Apr 2021 18:36:56 -0700 (PDT) References: <87pmyuyssi.fsf@gmail.com> <87y2dg4hik.fsf@tsdye.online> <87fszo47tx.fsf@gmail.com> <878s5fo005.fsf@gmail.com> User-agent: mu4e 1.5.11; emacs 28.0.50 From: Tim Cross To: Timothy Subject: Re: Concerns about community contributor support Date: Mon, 19 Apr 2021 08:45:21 +1000 In-reply-to: <878s5fo005.fsf@gmail.com> Message-ID: <87czur3vij.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::535; envelope-from=theophilusx@gmail.com; helo=mail-pg1-x535.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: , Cc: emacs-orgmode@gnu.org 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=1618796261; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc: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=h18/pq+VvCFhzf0qezhDacm8QjobJ6TENMA2n0CtRnE=; b=dpURIBg7TsgB/cV+bRLIObL91HSGB6GbG/lKiQbxZje8WcdgH7kq3vIPAsphLATu1R4BFO MUNzsYQf8Ml7VQGe3DBQPJthbkWBygxYL8zwzL/6TefsNxs1amrs9bpvhCz1QbSQRo3oPV Np97n1PylkxPiqa3b9NKI3qvWDdx6XW4OdVKS/GbtWjTFrMl4+WJ1hCSfmuQUrl34u0SVn a5GyNjxZGzf46yAIIgFIyuBPMQ9p3Bpnp0opaUZAfXHb0kCL0uxKVfVueUSEuiJWHIGf/l fYvvQLkkyYi3KlwAueohs3ml9HiMGZVBLuAmfAhKa9bwZYyhRWMaiRy8pM+PJQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1618796261; a=rsa-sha256; cv=none; b=kJ0mvA5e1V7s2IOF5ghkqUcaeYsEYEvEaGRunb6L7Vax9H/gNRfbOG4SYlFtER4n3AX+8q lYqEwZMEsbp77KF7b5yBTG8R17a1BWeZKTAtqdc+2QCWoGG1nHgTEEDGBWLHIwW0U7IsJ7 0TdDkW0AEC/TMYdaLufXTfYmVr8c9Fe9RWXq8fYmnUjPKDN0e60URt25xDwGlLElBNLbwN 6SxXZm5bVFVcpdD9IKIam5IsrkzwYPCRoC5+DSDHEigLGCipv7J+wRu9cxQuo3R69yBDf9 V2G6rACHNoFj0H/Me+xsdDA2clCLkyDg2QvbrNKgYEW8ObywR9uVwVD97shYnw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=TOxeNt5r; 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: -3.14 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=TOxeNt5r; 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: 475741E683 X-Spam-Score: -3.14 X-Migadu-Scanner: scn0.migadu.com X-TUID: DzeuLpzQ7ACO Timothy writes: > Tim Cross writes: >> This is a common development path for a successful project. Kent Beck >> (extreme/agile development) has been focusing a bit on this with his 3x >> development model (eXplore, eXpand, eXtract). (see >> https://medium.com/@kentbeck_7670/fast-slow-in-3x-explore-expand-extract-6d4c94a7539). >> To some extent, we are in an expand/extract stage for org mode. Focus is >> on addressing performance and extracting core functionality - new >> 'features' need to demonstrate a high level of 'return on investment'. >> At this stage, enhancing or extending the functionality is a slower and >> more cautious process which requires greater justification than was >> common in the 'explore' stage. > > Interesting link, thanks. Org being in the expand/extract stage > certainly rings true to me from my exposure. > > That said, I don't see why being in this stage of development means we > don't need to acknowledge people's attempted contributions. > This is probably just a reflection of how a largely community driven approach works. There isn't really anyone with a responsibility to respond or reply to a patch within some acceptable 'time'. There is a very limited number of people who have commit rights and who do apply patches etc. At this time, priority appears to be given to patches which fix existing behaviour (bug fixes) over ones which extend or modify existing behaviour (enhancements and new features). I suspect the level of response something receives is a reflection of the level of relevance or interest to others on the list. Personally, I don't respond to messages which either - Don't have relevance to how I use org mode. - I don't understand the objective or reason/rationale. - I don't agree or believe the idea is a good one. Sometimes I will reply if I feel (very subjective) the idea would have negative consequences in general or I think there is a simpler alternative solution. However, often I will take a wait and see approach before contributing anything. > My concern is centred around the lack of /response/ to people sending > in patches. Radio silence for *six months* after sending in a > contribution seems ridiculous to me. > I don't think it is ridiculous. I think it is more a reflection of how less formal and structured approaches work. I can understand why someone who has put in the effort to create and submit a patch would appreciate some feedback, but I'm not sure an expectation or desire for feedback is sufficient. Personally, I feel that if you make a patch submission, you sometimes need to 'sell' the patch. This is especially true if the patch is not a basic bug fix. Having developed a patch, it is easy to become very close to it and assume aspects of the patch or what it is proposing are self evident. It can be challenging to put yourself in the shoes of someone encountering the patch for the first time and consider how your submission will come across. Simply submitting the patch and expecting feedback may not be sufficient and followup posts will be required to either clarify, remind or encourage feedback. > This is an interesting thought. Putting aside the fact that this is > somewhat tangential to points I wished to discuss, I have a number of > reservations: > + Many patches are modifying core functionality, and would not be > suitable as an add-on (e.g. [1], [2], [3], and more) There is no limit on what additional external 'add on' packages can do. They can easily modify core functionality. This is one of the core benefits/strengths of lisp languages. I can redefine a core function in my add on package and provided my package is loaded after the core, my redefined version of the function will be what is executed when the core uses that function. For example, I have a heavily 'patched' version of org mode, but I never actually change the core org code. Instead, I have my own org configuration which redefines and modifies core functionality which I wanted changed to suit my requirements. I'm not totally clear about what sort of acknowledgement you want/expect for patch submissions. I get the impression it is more than a simple "thank you for your patch" and rather more detailed review/feedback of your patch. For the latter case, it is likely more a reflection of available resources - in particular, people with the necessary elisp skill to be able to review and provide valid feedback and available time for those limited resources. My observation, which is just one view, is that bug fixes get priority and other patches get attention based on a combination of community interest, available time and the 'squeaky wheel' principal. This relates to my point about needing to 'sell' your patch. For example, I had a quick look at some of the patches you referenced. None of them had any relevance to my use of org mode and none of them involved org functionality I am familiar with (from an internals perspective), which means I am not in a position to comment. > + This feels like it could become a bit of a graveyard of ideas. Yes, that is possible. However, I'm not sure that is necessarily a bad thing. My experience with software development is that around 80% of ideas never survive. This is partly why it is so important during the 'explore' stage of development to allow/support the rapid addition and implementation of new ideas. Ideas which seem good on the surface can often turn out to be less beneficial in reality or have unforeseen negative consequences which only become evident with broader use. It is survival of the fittest. Ideas which are really good, which satisfy a common use case and which avoid adverse impact tend to survive. Sometimes, this does mean a good idea fails because it wasn't the right time, it wasn't presented clearly or understood or because it needed more refinement or additional features/functionality which doesn't yet exist. > + Many patches aren't even being acknowledged. Given this, I am highly > suspicious that good additions will actually be moved into Org. This depends on a lot of factors - assignment of copyright, quality of code, type of addition, community desire for addition etc. My personal perspective is that we should actively discourage further additions or extensions to org mode and instead focus on making org mode itself a core, clear and well documented and maintained mode of common basic functionality and have external packages which take that common functionality and wrap/customize/extend it to provide more high-level functionality. I think it is a mistake to try and make core org-mode everything to everyone. I use org mode a lot - daily and it is linked into almost every workflow I have. However, the actual org mode features I use are quite limited. For example, I don't publish web sites with org mode or use it to generate gnuplot graphs or code python blocks. I also don't want additions, extensions or enhancements to publishing, generation of gnuplot graphs or enhancements to python source block handling to impact, alter or otherwise affect what I do. However, every time you modify the core org-mode package, this potential exists. > + This complicates the development model. I actually feel it would make things clearer. Development of org-mode itself would focus on bug fixes api refinement and performance improvements. Everything else would depend on add on packages, which might adopt completely different development models. Like with most things, there are pros and cons. This reply is already far too long, so I won't go into further detail. To avoid confusion, I'm not suggesting all is fine and perfect. There is always room for improvement. However, we need to work within the resource constraints we have and adjust our expectations to be within those constraints. We can probably do better with expectation management and perhaps some more details on worg would be helpful wrt contributing, acknowledgement and feedback. Maintaining a community takes effort, especially a community with the diverse backgrounds, languages, cultures and different social norms as this one. Getting the right balance is challenging. While it is good to raise and identify areas we may be failing in or which need improvement, we also need to try and identify viable solutions. Along these lines, I wonder if it would be worth having a section on worg for non-bugfix patches where the community could provide feedback. This could be as simple as basic "I think this is a good/bad idea" to more structured feedback, such as code review etc. Personally, I'd like it if we had something like gitlab (not github) which would make it easier for people to add/review patches. However, even this requires resources to maintain. -- Tim Cross