emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Timothy <tecosaur@gmail.com>
To: Tim Cross <theophilusx@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Concerns about community contributor support
Date: Thu, 22 Apr 2021 10:35:30 +0800	[thread overview]
Message-ID: <87tunzkpvx.fsf@gmail.com> (raw)
In-Reply-To: <87eef3f5qs.fsf@gmail.com>

Tim Cross <theophilusx@gmail.com> writes:

> ian martins <ianxm@jhu.edu> writes:
>> On Wed, Apr 21, 2021 at 3:45 PM Tim Cross <theophilusx@gmail.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.


  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:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tunzkpvx.fsf@gmail.com \
    --to=tecosaur@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=theophilusx@gmail.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


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).