Re: Concerns about community contributor support

[Tim Cross <theophilusx@gmail.com>]

ian martins <ianxm@jhu.edu> writes:

> On Wed, Apr 21, 2021 at 3:45 PM Tim Cross <theophilusx@gmail.com> wrote:
>
>  Responding to essentially just flag you have seen the patch message
>  really only adds noise and may even 'drown out' those responses which
>  add real 'value' to any discussion. I also doubt that asking people to
>  do this would actually result in any actual change of behaviour by
>  subscribers.
>
> 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. 

responses to patches really need to come from community members who are
sufficiently interested in the patch to examine it or make comment on
how useful they feel it would be. To some extent, if someone submits a
patch and hears nothing, either they have failed to clearly explain what
the patch does (and therefore did not tweak any interest) or it is a
patch to introduce functionality which is of low interest to community
participants.

I think you can classify patches into 3 basic types -

1. Bug fixes. Patches which do not change functionality, but address
bugs and performance bottlenecks in existing features. At present, this
type of patch seems to get applied fairly quickly.

2. Patches which extend existing functionality. This type of patch
requires significant consideration and evaluation. They can be time
consuming to assess and a call needs to be made as to whether the
additional complexity such enhancements add can justify the increased
maintenance overhead such enhancements introduce. This is particularly
challenging with org mode because org supports a diverse and sometimes
complex range of workflows. Verifying an enhancement will not have
adverse impact on some of these workflows is difficult and time
consuming. Even apparently simple and straight-forward changes can have
unexpected impact - consider for example the enhancement to support
electric indent mode. This seemed fairly straight-forward and was a
change which made org mode aligned with other Emacs modes and helps
improve consistency withing Emacs across modes. However, it has had some
adverse impact and caused some confusion because of how it interacts
with existing org behaviour and configuration settings, such as with org
indentation behaviour.

3. Patches which introduce new functionality. This type of patch also
requires considerable resources to evaluate and adds to overall
maintenance load. It is one thing to write an extension, but a
completely different thing to maintain it over time. Even assessing the
real demand for such extensions is challenging and time consuming and
represents a significant demand on volunteers time.

Asking volunteers to respond to patches of type 2 and 3 within some
nominated time period is probably unreasonable. It also runs the danger
of discouraging people from stepping up to volunteer to help maintain
parts of org. 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.

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. 

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. 

-- 
Tim Cross