emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Timothy <tecosaur@gmail.com>
To: Eric S Fraga <e.fraga@ucl.ac.uk>
Cc: emacs-orgmode@gnu.org
Subject: Re: Concerns about community contributor support
Date: Tue, 20 Apr 2021 11:54:43 +0800	[thread overview]
Message-ID: <8735vlobjx.fsf@gmail.com> (raw)
In-Reply-To: <87wnsyy4ia.fsf@ucl.ac.uk>

Hi Eric,

Thanks for writing in and sharing your thoughts. I have some specific
comments that you may find below, but more generally: I get the
impression you approached this from the view of Org development and
patch merging.

In short, while I appreciate that Org development should be a considered
process and that maintainer time is limited --- I think we could improve
how well we communicate this to contributors, and maybe even our
treatment of contributions.

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> Hello all,
> I've avoided saying anything in this discussion but not from lack of
> empathy with the initial post.  Many valid points have been made in the
> thread and I understand the frustrations.  My own view is that org is
> now at a different stage than it was some years ago.  It is a
> feature-full package which generally works well for a very *large* set
> of use cases.  As a result, it is being used by many people and so is no
> longer a niche product.

I can't say I see how being used by a large number of people and growing
beyond a niche product means that we can't set expectations for patches
and/or responsiveness. Though I see you go in a slightly different
direction below...

> And, hence:
> On Saturday, 17 Apr 2021 at 23:29, Thomas S. Dye wrote:
>> But, my sense is that patches to Org mode proper will continue to be
>> adopted slowly and deliberately.
> and this is as it should be.  I *rely* on org for my work these days.  I
> would not want the type of chaotic development we had in the early days,
> development that would affect the stability of the package.  New
> features need to be considered very carefully.

Indeed, but a lot don't seem considered, they just seem ignored.
Particularly with a lack of communication, this can leave the
contributor wondering whether they need to resend there email, bump it,
wait for a particular maintainer to have a look at it, explain the
intent further, etc. and I don't think leaving such uncertainty to grow
is very nice.

> But, also, as has also been said: the "maintainers" are volunteers and
> do have other things to do.  Stating that there is an expectation for
> them to answer within a particular time frame is not fair.

Maybe I'm not being entirely reasonable, but I would have thought
something like "a cursory response within two months of submitting your
patch" wouldn't be too hard to uphold; particularly when a cursory
response could just be "we've been rather busy as of late, we'll get
back to you on this in the future".

> If there is a feature *you* need that is not there, the beauty of Emacs
> is that you can have that feature, if you have implemented it,
> regardless of whether it is accepted in the main org package.  A large
> part of my org environment is code that I have written myself to meet my
> needs; my org specific config file is 3000 lines.  Some bits along the
> way have migrated into org or have informed org features but I can work
> the way I want to or need to regardless of whether the features are in
> the main code or in my own config.
> The excellent work that was done in creating version 9 (or maybe 8?) in
> providing a wide range of hooks and filters means that practially
> everything is customisable without requiring changes to org itself.
> And this leads back to the first point: I want org to exhibit a certain
> level of stability now as otherwise much of my workflow would break.  I
> suspect many others have this same requirement.  And the maintainers are
> very good at avoiding breakage when new features are accepted but this
> takes time to evaluate the impact of those new features.

I too appreciate the versatility of elisp, and the way Org has been
constructed that allow it to be modified so heavily by the end user ---
I should know, I have ~4k lines of Org modification in my config.

However, this does not preclude good ideas for Org modification being
merged in. If I have a bugfix, or a very useful modification to Org,
that's great for me, but it's good to share the improvement upstream.
Isn't this a large part of the benefit of an open source development

And when a patch does need to be carefully considered over a period of
months or years, surely it's good to communicate that to the author
instead of leaving them with silence?

Please let me know what your thoughts are,


  reply	other threads:[~2021-04-20  3:55 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 [this message]
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
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=8735vlobjx.fsf@gmail.com \
    --to=tecosaur@gmail.com \
    --cc=e.fraga@ucl.ac.uk \
    --cc=emacs-orgmode@gnu.org \
    --subject='Re: Concerns about community contributor support' \


* 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:


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