From: Timothy <firstname.lastname@example.org> To: Tim Cross <email@example.com> Cc: firstname.lastname@example.org Subject: Re: Concerns about community contributor support Date: Thu, 22 Apr 2021 10:35:30 +0800 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> Tim Cross <email@example.com> writes: > ian martins <firstname.lastname@example.org> writes: > >> On Wed, Apr 21, 2021 at 3:45 PM Tim Cross <email@example.com> 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
next prev parent reply other threads:[~2021-04-22 2:36 UTC|newest] Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-16 18:43 Timothy 2021-04-17 23:29 ` Thomas S. Dye 2021-04-18 1:56 ` Tim Cross 2021-04-18 19:39 ` Timothy 2021-04-18 22:45 ` Tim Cross 2021-04-19 21:43 ` David Masterson 2021-04-19 22:21 ` Gustav Wikström 2021-04-23 0:16 ` David Masterson 2021-04-19 23:46 ` Tim Cross 2021-04-20 8:21 ` Tom Gillespie 2021-04-23 0:34 ` David Masterson 2021-04-20 9:28 ` Jean Louis 2021-04-23 0:38 ` David Masterson 2021-04-18 5:04 ` Timothy 2021-04-18 18:45 ` Thomas S. Dye 2021-04-18 19:12 ` Timothy 2021-04-18 19:46 ` Thomas S. Dye 2021-04-18 19:59 ` Timothy [not found] ` <a64adc3de7be49039372851ea31e4f7c@VI1PR0102MB3327.eurprd01.prod.exchangelabs.com> 2021-04-19 10:04 ` Eric S Fraga 2021-04-20 3:54 ` Timothy 2021-04-19 22:07 ` Gustav Wikström 2021-04-21 9:33 ` Jean Louis 2021-04-21 9:50 ` Tim Cross 2021-04-21 10:25 ` Heinz Tuechler 2021-04-21 12:55 ` ian martins 2021-04-21 13:07 ` Timothy [not found] ` <1c557c0e35e04440ba2dadfe57e5b590@VI1PR0102MB3327.eurprd01.prod.exchangelabs.com> 2021-04-21 13:27 ` Eric S Fraga 2021-04-21 15:31 ` ian martins 2021-04-21 15:38 ` Bruce D'Arcus 2021-04-21 19:35 ` Tim Cross 2021-04-22 0:36 ` ian martins 2021-04-22 0:48 ` Tim Cross 2021-04-22 2:35 ` Timothy [this message] 2021-04-22 5:14 ` Maintaining babel packages — a list of packages that need help? Dr. Arne Babenhauserheide 2021-04-22 10:10 ` ian martins 2021-04-26 7:25 ` Bastien 2021-04-22 10:00 ` Concerns about community contributor support ian martins 2021-04-21 19:31 ` Tim Cross 2021-04-25 4:30 ` Bastien 2021-04-25 5:52 ` Contributor Steward role (was Re: Concerns about community contributor support) Timothy 2021-04-25 7:13 ` Bastien 2021-04-25 6:17 ` Concerns about community contributor support Tim Cross 2021-04-25 7:19 ` Bastien 2021-04-26 0:23 ` Tim Cross 2021-04-26 5:00 ` Bastien 2021-04-26 6:07 ` Tim Cross 2021-04-26 7:34 ` Bastien 2021-04-25 10:10 ` Help with reproducing bugs reported on this list (was: Concerns about community contributor support) Bastien 2021-04-27 6:28 ` Help with reproducing bugs reported on this list Bastien 2021-04-25 21:40 ` Concerns about community contributor support Nick Savage 2021-04-26 7:22 ` Bastien 2021-04-29 14:07 ` D 2021-04-29 14:16 ` Bastien 2021-04-29 14:44 ` D 2021-04-29 14:29 ` Ihor Radchenko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Concerns about community contributor support' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).