Org-mode mailing list
 help / color / mirror / Atom feed
From: Tim Cross <>
Subject: Re: Concerns about community contributor support
Date: Sun, 18 Apr 2021 11:56:13 +1000
Message-ID: <> (raw)
In-Reply-To: <>

"Thomas S. Dye" <> 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
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

  reply	other threads:[~2021-04-18  2:59 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-16 18:43 Timothy
2021-04-17 23:29 ` Thomas S. Dye
2021-04-18  1:56   ` Tim Cross [this message]
2021-04-18 19:39     ` Timothy
2021-04-18 22:45       ` Tim Cross
2021-04-19 21:43     ` David Masterson
2021-04-19 22:21       ` Gustav Wikström
2021-04-23  0:16         ` David Masterson
2021-04-19 23:46       ` Tim Cross
2021-04-20  8:21         ` Tom Gillespie
2021-04-23  0:34           ` David Masterson
2021-04-20  9:28       ` Jean Louis
2021-04-23  0:38         ` David Masterson
2021-04-18  5:04   ` Timothy
2021-04-18 18:45     ` Thomas S. Dye
2021-04-18 19:12       ` Timothy
2021-04-18 19:46         ` Thomas S. Dye
2021-04-18 19:59           ` Timothy
     [not found] ` <>
2021-04-19 10:04   ` Eric S Fraga
2021-04-20  3:54     ` Timothy
2021-04-19 22:07 ` Gustav Wikström
2021-04-21  9:33   ` Jean Louis
2021-04-21  9:50     ` Tim Cross
2021-04-21 10:25       ` Heinz Tuechler
2021-04-21 12:55         ` ian martins
2021-04-21 13:07         ` Timothy
     [not found]         ` <>
2021-04-21 13:27           ` Eric S Fraga
2021-04-21 15:31             ` ian martins
2021-04-21 15:38               ` Bruce D'Arcus
2021-04-21 19:35                 ` Tim Cross
2021-04-22  0:36                   ` ian martins
2021-04-22  0:48                     ` Tim Cross
2021-04-22  2:35                       ` Timothy
2021-04-22  5:14                         ` Maintaining babel packages — a list of packages that need help? Dr. Arne Babenhauserheide
2021-04-22 10:10                           ` ian martins
2021-04-26  7:25                           ` Bastien
2021-04-22 10:00                       ` Concerns about community contributor support ian martins
2021-04-21 19:31             ` Tim Cross
2021-04-25  4:30 ` Bastien
2021-04-25  5:52   ` Contributor Steward role (was Re: Concerns about community contributor support) Timothy
2021-04-25  7:13     ` Bastien
2021-04-25  6:17   ` Concerns about community contributor support Tim Cross
2021-04-25  7:19     ` Bastien
2021-04-26  0:23       ` Tim Cross
2021-04-26  5:00         ` Bastien
2021-04-26  6:07           ` Tim Cross
2021-04-26  7:34             ` Bastien
2021-04-25 10:10   ` Help with reproducing bugs reported on this list (was: Concerns about community contributor support) Bastien
2021-04-27  6:28     ` Help with reproducing bugs reported on this list Bastien
2021-04-25 21:40   ` Concerns about community contributor support Nick Savage
2021-04-26  7:22     ` Bastien
2021-04-29 14:07 ` D
2021-04-29 14:16   ` Bastien
2021-04-29 14:44     ` D
2021-04-29 14:29   ` Ihor Radchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Org-mode mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror list/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 list list/ \
	public-inbox-index list

Example config snippet for mirrors.
Newsgroups are available over NNTP:

AGPL code for this site: git clone