Re: Concerns about community contributor support

[Timothy]

Thomas S. Dye <tsd@tsdye.online> writes:

>> Hmmm, what constitutes noise?
>>
> Good question.  I suppose like most words the meaning changes over time.  
> Early
> on, posts along the lines of "Wouldn't it be cool if Org mode would do this?"
> were given more space than they seem to be today.  Tim Cross points out a
> project trajectory that appears to be common and would explain why.  At a more
> concrete level, I can offer several of my posts to the list :)

Follow up: What should be the response to "noise", because I don't think
it should be a cold shoulder.

>> I think here there may have been a minor misunderstanding
>> /miscommunication. Reading this paragraph I get the sense you read my
>> email as complaining about a delay in merging patches, however this is a
>> separate ---if related--- point to what I intended to raise: the
>> lack of /response/ to patches.
>>
>> 1. [snip]
>> 2. [snip]
> So, something in between merging (or not) and appearing on the public list 
> that
> Bastien keeps?

I'll try to clarify my meaning:
+ Patches are sent in
+ The /do/ appear on the public list
+ Months go by without anyone even replying to the patch

I think it's fair to expect something along the lines of: "Not sure
about this, will require further thought", "Looks good, but want to wait
for X to approve", "Not quite sure why this is a good idea, please
explain further", or one of a hundred other suitable cursory responses.

Instead, there are currently 24 patches listed on
https://updates.orgmode.org/#patches which have not received a single
response. Then, there are also a large number of other patches with 1-2
cursory replies that seem stuck in limbo (e.g. [1]), with no signs of
being merged or rejected (better than 0 replies, but still not good).

>> Once again, with reference to my earlier paragraph, IMO slowed
>> development is one thing, not responding at all to attempted
>> contributors for months on end another. It is the latter which I seek to
>> improve. I can, have, and will try to help with this myself; but I think
>> we would benefit from a "community effort" and a discussion on what the
>> best way to improve this is.
>>
>
> What do you think of Tim Cross' suggestion that a way forward is for "new
> features and enhancements to be initially implemented as add on contribution
> packages rather than as extensions/enhancement to the core 'org-mode' 
> package"?
> This sounds good to me, but I'm not much of a programmer and lack the ability 
> to
> suss out its ramifications fully.  I can see how it would ease Org mode
> maintenance, though.

I'm going to reply to Tim Cross' email, but a short version of my
current thoughts is:
+ This feels like a little bit of a tangent from the lack of response
+ Many patches are modifying core functionality, and would not be
  suitable as an add-on (e.g. [2], [3], [4], and more)
+ I'm concerned that good changes could quickly make there way here and
  never make their way into Org

> All the best,
> Tom

--
Timothy

[1]: [PATCH] ob-lilypond: allow user configuration of header-args
     
https://orgmode.org/list/CANwLyLNCUDEqrtLe9DxB+xZg9T-DWfmfHzrPMuqcUZLZW347Tg@mail.gmail.com/
[2]: [PATCH] Add org-meta*-final-hook
     
https://orgmode.org/list/CAOywxZg1cBL07THLZXHBBCzm6te2vMtqnmM0w63331gybrjZuw@mail.gmail.com/
[3]: [PATCH] ob-C.el: Fix a number a bugs related to table parameters
     https://orgmode.org/list/874kkqao1e.fsf@bzg.fr/
[4]: [PATCH] Fontification for inline src blocks
     https://orgmode.org/list/87pmzf4bd0.fsf@gmail.com/