Re: Concerns about community contributor support

[Timothy]

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
model?

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,

Timothy.