Re: Concerns about community contributor support

[Tim Cross <theophilusx@gmail.com>]

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

> Aloha Timothy,
>
> working on Org mode (my interpretation), Nicolas Goaziou took over most of the
> coding work.  His brief was clearly to put the Org mode code into better order,
> which he did with astonishing efficiency and expertise (at least from my often
> ignorant and confused perspective).  His work on the syntax, exporter, linter,
> and manual represents IMHO an outstanding contribution to Org mode.  I'm sure
> there are other important contributions that I'm not remembering right now.  My
> point is that the project changed from one that was expanding its own vision of
> what it might be to one that was working to ensure that it wouldn't collapse
> from its own weight.
>

Totally agree. The work Nicolas has put in to consolidate, stabilise and
clarify the org code base has been critical to the long term viability
of the project.  I very much appreciate the work he has contributed and
the many times he has assisted me in understanding how things work
within org-mode.

> Kyle Meyer is the next step in this direction, whose efforts have helped tame
> the discussions on the Org mode list with a remarkable facility for threading
> together the various strands of discussion, some of which have histories that
> comprise several years. Combined with a command of git, his work has brought the
> discussion into closer contact with the development of the code base.
>

Also agree. Getting the right balance between features, stability and
maintenance is extremely challenging. This is especially so with
org-mode as it has a level of flexibility which makes for a very wide
set of use cases. Identifying what should be part of 'core' and what
would be better off as an extension or add-on is often challenging. What
may seem like a great addition/enhancement for one may be of no benefit
to another or may actually complicate their use case. It can be
challenging to understand and interpret all these different perspectives
and determining the optimal forward direction. 


> These changes mean that contributions need to be checked for contributions to
> Nicolas' project and also fit into the history of discussion and development.
> The Org mode project now resembles a scholarly discipline that moves slowly and
> deliberately toward a more or less well defined goal.  The days when Carsten
> would bang out a new feature during his train ride home from work are gone.

This is a common development path for a successful project. Kent Beck
(extreme/agile development) has been focusing a bit on this with his 3x
development model (eXplore, eXpand, eXtract). (see
https://medium.com/@kentbeck_7670/fast-slow-in-3x-explore-expand-extract-6d4c94a7539).
To some extent, we are in an expand/extract stage for org mode. Focus is
on addressing performance and extracting core functionality - new
'features' need to demonstrate a high level of 'return on investment'.
At this stage, enhancing or extending the functionality is a slower and
more cautious process which requires greater justification than was
common in the 'explore' stage.  

>
> Bastien did recently call for maintainers, though IIRC he was interested in ox-*
> and ob-* maintainers more than org-* maintainers.  If enough good programmers
> heed his call, then there might be some progress on the concerns you raise.
> But, my sense is that patches to Org mode proper will continue to be adopted
> slowly and deliberately.  It would be a shame if that pace put off talented
> programmers, but my sense FWIW is that the pace might be necessary until the
> code base is fully tamed.
>

From my perspective, I see bug fixes applied fairly quickly.
Enhancements and extensions are applied more conservatively, which I
think is the correct approach. 

I suspect the best model for moving 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.
Such packages, if found to be popular or useful to a large number of
org-mode users could then be considered for inclusion as part of the
main org-mode package. The nature of elisp makes this type of model very
suitable as you can modify almost any aspect of org-mode via add on
packages in a consistent and stable manner and avoid impacting the core
functionality until the extension/enhancement has matured sufficiently.


-- 
Tim Cross