"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