[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Concerns about community contributor support

From: Timothy
Subject: Re: Concerns about community contributor support
Date: Tue, 20 Apr 2021 11:54:43 +0800
User-agent: mu4e 1.4.15; emacs 28.0.50

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 via email to

[Prev in Thread] Current Thread [Next in Thread]