From: Tim Cross <firstname.lastname@example.org> To: email@example.com Subject: Re: Concerns about community contributor support Date: Sun, 18 Apr 2021 11:56:13 +1000 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> "Thomas S. Dye" <firstname.lastname@example.org> 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
next prev parent 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] ` <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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Concerns about community contributor support' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.git 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).