[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Concerns about community contributor support

From: Timothy
Subject: Re: Concerns about community contributor support
Date: Mon, 19 Apr 2021 03:39:38 +0800
User-agent: mu4e 1.4.15; emacs 28.0.50

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 via email to

[Prev in Thread] Current Thread [Next in Thread]