From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id cFeDGRThgGCQJgAAgWs5BA (envelope-from ) for ; Thu, 22 Apr 2021 04:36:04 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id qBggFRThgGA9BgAAB5/wlQ (envelope-from ) for ; Thu, 22 Apr 2021 02:36:04 +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 904D524AB4 for ; Thu, 22 Apr 2021 04:36:03 +0200 (CEST) Received: from localhost ([::1]:56846 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lZPCD-00005Q-6w for larch@yhetil.org; Wed, 21 Apr 2021 22:36:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39436) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lZPBq-00004s-KU for emacs-orgmode@gnu.org; Wed, 21 Apr 2021 22:35:38 -0400 Received: from mail-pj1-x1033.google.com ([2607:f8b0:4864:20::1033]:33372) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lZPBo-00044O-MQ for emacs-orgmode@gnu.org; Wed, 21 Apr 2021 22:35:38 -0400 Received: by mail-pj1-x1033.google.com with SMTP id kb13-20020a17090ae7cdb02901503d67f0beso1942586pjb.0 for ; Wed, 21 Apr 2021 19:35:36 -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:in-reply-to:message-id :date:mime-version; bh=rJJTwOc1xPZFffYoSLL7cCvWjMxJ5aoDgdqYfWek8h0=; b=c31CZ9BwPD2qhwIvdJQi1g/UlqamvV+de8ade8MuI/PLYGG53/b5uXpSmrdPYoBZZY SFGf01OP/Njy5rUNbo1iNawmV+SPYAmXNgpa8vUHUn3deUjjlj6ArOhxvKJJuFaRnZD8 rQFzYkipC2vMcBa4kggJfnq1dflDztBkcaVl/ci8gz64VLwp7Hlfcw7pTv+M5KN2fsLq HQ52vT4rdhOLAGkKbJUrMKBDFTnaK+SRgcqLPkj0JyoONLYqVL/FKT9z9qfUO+vCtPYP TAaiMCue2aMNTzoI83i2uKWajQGa5+/oCdc05B/14hV0+rgX2n/RQ8NAWEgPPY7Gcutb NCSA== 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 :in-reply-to:message-id:date:mime-version; bh=rJJTwOc1xPZFffYoSLL7cCvWjMxJ5aoDgdqYfWek8h0=; b=Hs73M2/IaPNQXclxGY7ngqOPfwFp/oEBJZX4IWExrwy/sCCifPk4EKqqU7qgCZeZlr /352DGM/1AD3zwXYUMV1ghn0I92gIcR5XuWD8LOQ6mo229UA/KmaYOowW8Fwq++CDTIl YOzBGgZNuho9jxVTkvGoT0I1R1oSBgHM9OGgP7r+UUQADgs2smSkMO/nsqz16AzoOFUT 8UYWsfdIh6Hhc1tfwGUxi1GSSYGrjxDsWJt+Zu0nPKhiB4JtOypv9NNnEqGCTxbNtjfs r0QpINS0rItTwp1P7zm8itImr/pjWK4bwOfQn82lhgVLlORDoD9Fva2ACkLoonkzSNyK sZzw== X-Gm-Message-State: AOAM530jPiCDUfrxyBr3XCQ2T+hxjBi7k9OyBmcYk2R4LsAnmYIhqJ31 qfBqn+iANvmnXRsuMPZdhJw= X-Google-Smtp-Source: ABdhPJz/I+W8+ZvwFr1Vxoht97uyLyvfzr3no5iadx/2spYsQA8b7vl8yXVXsGojFUww8n7gU9IdzA== X-Received: by 2002:a17:902:a40e:b029:e9:7253:8198 with SMTP id p14-20020a170902a40eb02900e972538198mr1292682plq.82.1619058934949; Wed, 21 Apr 2021 19:35:34 -0700 (PDT) Received: from localhost (180-150-91-8.b4965b.per.nbn.aussiebb.net. [180.150.91.8]) by smtp.gmail.com with ESMTPSA id s22sm579040pjs.42.2021.04.21.19.35.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Apr 2021 19:35:34 -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> <87eef3f5qs.fsf@gmail.com> User-agent: mu4e 1.4.15; emacs 28.0.50 From: Timothy To: Tim Cross Subject: Re: Concerns about community contributor support In-reply-to: <87eef3f5qs.fsf@gmail.com> Message-ID: <87tunzkpvx.fsf@gmail.com> Date: Thu, 22 Apr 2021 10:35:30 +0800 MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::1033; envelope-from=tecosaur@gmail.com; helo=mail-pj1-x1033.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=1619058963; 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=rJJTwOc1xPZFffYoSLL7cCvWjMxJ5aoDgdqYfWek8h0=; b=Jwj2iqcu6PyT6EXv48wHS5mIAOzwQj4tanZkM4MzXMPSQDCd4x+3hQdEjHZ5U507g+qMjt 8/32EnVu2LYXegueF1I6gC3LkwOasohxlMgD07HrC48l3u0zcvn3cq5yYMjbILqF374xf8 2X1jr/fGEI3Z3TrbokAXedXDIURXlUaCq3Qth6N9fSDUTHJfEliygcuapL9aPR8W8MU4yM 6OJ0HbGjdlHgH79luiV4MNlWDX38jIpViNbPs9FsOmZdcc9fI2sLEqTWrqP42AgPiJlC2g 3nOxvNfZfBHb7JSSEJD6iut30dW8exF4S4k7+SpMyDOdPbQN8TGvDRDh57rRNQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1619058963; a=rsa-sha256; cv=none; b=bVmtiTfnevSa76pl/ZrfFKhusYcAIDqSN3h4MTnO/wgDJIp5fY28eVoktJOmI89zmRzNSL lVd3ubXng/9p+K2bMR7YuTAwLvjLITVh8TUbLScgqZQX1I66ErjqQb+MZ6KjMgK1jHqvM5 6tpoxuzTPIqeSEFAvVeSh1upJ7s1AEl4zBBAKp53FUKebgkbDIoK7ElYlrqsYWsfn9fQhV yhmiT/amcGq7KNmDywmI4cEzTyOmqVLKHJKApV7RapZN/qwa64rWgWi3RQCw/gGTXJGe39 p8TWonAaN+kIol8+SWGymOLQUbkzi+gQwC1lN5gKeydYUEuaCDeq9kYe6xWKSw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=c31CZ9Bw; 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=c31CZ9Bw; 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: 904D524AB4 X-Spam-Score: -1.64 X-Migadu-Scanner: scn0.migadu.com X-TUID: mCvfuGxC/bfi Tim Cross writes: > ian martins writes: > >> On Wed, Apr 21, 2021 at 3:45 PM Tim Cross wrote: >> >> [Noise] >> >> 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. As far as I know the only call for help maintaining Org has been with babel packages. Otherwise you would have seen me volunteering :P I'd like to do more if I get the opportunity. > [snip] > > I think you can classify patches into 3 basic types - > > 1. [Fixes] > > 2. [Extending existing stuff] > > 3. [New stuff] > > Asking volunteers to respond to patches of type 2 and 3 within some > nominated time period is probably unreasonable. I'd like to suggest that a response can just be "We've got your patch, it will take some time to go through and see ow it interacts with Org". > It also runs the danger of discouraging people from stepping up to > volunteer to help maintain parts of org. TBH I don't see how being asked to provide the odd cursory response would be that off-putting. 50 currently patches needing a response per year / say 3 maintainers ~= cursory quick email every 2-4 weeks on average just to say a patch has been seen, thanks for submitting it, and maybe that it might take a while to be reviewed. > 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. I think this would be a very good idea, I'll say a bit more below where you mention Worg. > 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. I think volume of email replies saying "I'd like this" is a bad measure for a few reasons. (1) I get the sense there's a fairly high degree of tacit approval, (2) I've seen the same idea presented simply at different times get very different responses based on how the initial replies reframed/directed the discussion. Additionally, if people who like it can "just use it", a patch may be well-liked and used a lot but not have many peoples speaking in support of it in the ML. In other words, I think that such a system could be too fickle. I suspect some good patches will easily "fall through the cracks" with such a method. I can think of a several merged patches which I consider a good idea which would not fare well under such a system. Then there's another concern if you're modifying parts of Org's internals --- they can be tweaked in Org, and then the overridden methods can cause errors in a number of ways. I know this very well, as I do this sort of thing in a few places in my config, e.g. I was affected by a change in org--mks-read-key. Is a patch author going to be interested in maintaining their patch in the hope that it one day gets merged with Org? This seems like a bit of a stretch to me. > 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. Fantastic! I think such an entry would be a big improvement, and I hope that such an addition would help prevent contributors from feeling surprised/disappointed. I think a short entry on this may also be a good idea for orgmode.org/contribute.html. -- Timothy