emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Timothy <tecosaur@gmail.com>
To: Tim Cross <theophilusx@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Concerns about community contributor support
Date: Mon, 19 Apr 2021 03:39:38 +0800	[thread overview]
Message-ID: <878s5fo005.fsf@gmail.com> (raw)
In-Reply-To: <87fszo47tx.fsf@gmail.com>

Tim Cross <theophilusx@gmail.com> writes:

>> Nicolas Goaziou [...]
> 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 [...]
> 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.

Thank you for these points. They are separate to my concerns about the
lack of response to patches, but worth noting in the overall context of
the development of Org mode.

>> 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.

Interesting link, thanks. Org being in the expand/extract stage
certainly rings true to me from my exposure.

That said, I don't see why being in this stage of development means we
don't need to acknowledge people's attempted contributions.

> 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'm not sure if this is a deliberate tangent, or a miscommunication in
my original email, but how quickly patches are *applied* is not
something I mentioned at all in my original email.

My concern is centred around the lack of /response/ to people sending
in patches. Radio silence for *six months* after sending in a
contribution seems ridiculous to me.

> 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.

This is an interesting thought. Putting aside the fact that this is
somewhat tangential to points I wished to discuss, I have a number of
+ Many patches are modifying core functionality, and would not be
  suitable as an add-on (e.g. [1], [2], [3], and more)
+ Many patches aren't even being acknowledged. Given this, I am highly
  suspicious that good additions will actually be moved into Org.
+ This feels like it could become a bit of a graveyard of ideas.
+ This complicates the development model.


[1]: [PATCH] Add org-meta*-final-hook
[2]: [PATCH] ob-C.el: Fix a number a bugs related to table parameters
[3]: [PATCH] Fontification for inline src blocks

  reply	other threads:[~2021-04-18 19:40 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
2021-04-18 19:39     ` Timothy [this message]
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] ` <a64adc3de7be49039372851ea31e4f7c@VI1PR0102MB3327.eurprd01.prod.exchangelabs.com>
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]         ` <1c557c0e35e04440ba2dadfe57e5b590@VI1PR0102MB3327.eurprd01.prod.exchangelabs.com>
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: https://www.orgmode.org/

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

  git send-email \
    --in-reply-to=878s5fo005.fsf@gmail.com \
    --to=tecosaur@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=theophilusx@gmail.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).