From: Tim Cross <theophilusx@gmail.com>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: Jarmo Hurri <jarmo.hurri@iki.fi>, emacs-orgmode@gnu.org
Subject: Re: Volunteering to maintain ob-asymptote.el within Org
Date: Wed, 27 Jul 2022 10:03:28 +1000 [thread overview]
Message-ID: <86fsinid4z.fsf@gmail.com> (raw)
In-Reply-To: <87lesgd3x0.fsf@localhost>
Ihor Radchenko <yantar92@gmail.com> writes:
> Another question is long-term maintainability. We have a limited
> manpower and cannot cater too many support requests or take care about
> parts of code not used by most people. After removing org-contrib over a
> year ago, your email is the first issue raised regarding ob-asymptote
> removal. Since you are volunteering to maintain it, things gets easier.
> However, the final decision is after Bastien.
>
and I don't think it is a decision which has to be made now.
It is fantastic someone has stepped up to maintain this code. However,
it may be wise to wait 12 months before making an important decision
like moving it into core. While moving something into core may seem
easy, moving it back out tends to be more problematic and require more
change management to avoid unexpected impact to org users (including
none users of this module who could also be impacted by any breakage
introduced).
As this module has never been part of org core, there is considerable
work which would need to be done as a prerequisite e.g. updating the
manual and adding documentation and examples, adding unit tests
etc. Therefore, I don't think there is any need to make a decision on
this now.
I also think it is prudent to allow any new maintainer some period of
time to get to grips with the maintenance role. Once something becomes
part of core, maintenance demands can increase significantly. For
example, any significant change in org mode or Emacs will need to be
addressed in a timely manner to prevent issues with ob-asymptote
impacting org usage generally. From a maintainers perspective, it often
means having to run multiple versions of both Emacs and org mode,
keeping an eye on org and Eamcs bug reports and responding to user
queries.
In addition to all of this, there is also the unexpected burden of
success. If you actually do a good job, the amount of maintenance work
can actually increase. I speak from personal experience. I took over
maintenance of a small nodejs module about 5 years ago. At the time,
this module had only a few thousand downloads per week. It now averages
around 225k weekly downloads. Code maintenance has not been a
problem. However, user maintenance has been a considerable burden. I
have ended up spending far more time writing documentation, providing
usage examples and helping users than I expected. I would estimate over
80% of all the issues raised by users are due to errors in user code
(most have nothing to do with my module, but I still need to
investigate to verify that). What makes matters harder is that the
module concerned is not one I need any longer. At some point, I will
likely hand maintenance on (assuming someone wants it of course). The
thing to note is that the level of expected maintenance and actual
maintenance can be surprisingly different and it doesn't take much
before that role can become a burden, especially if you have other
demanding work needing attention.
Finally, we don't actually know what the user base size for asymptote
currently is or could be. I've used org for many years and I've used
plantuml, ditta, graphviz and gnuplot, but I've never used
ob-asymptote. While this may appear to be a critical tool in some use
case groups, it may not be an overall critical module for the overall
org user base. I'm also not convinced that being in contrib rather than
core is really an impediment as suggested. Now that org-contrib is part
of non-gnu ELPA and that archive is automatically configured in new
versions of Emacs, adding org-contrib is fairly trivial. I suspect many
users already add it as part of their setup anyway.
While personally I don't agree with adding more things into core, my
main point is we don't need to make this decision now. We can wait 12
months and if whoever is maintaining the mode still wants to see it
moved into core and if all the prerequisite work has been completed, we
can then put it to the community and see what the overall consensus
is. In the meantime, the mode maintainer can work on building the use
base and strengthening their case for inclusion and getting a real feel
for what the maintenance demands are.
next prev parent reply other threads:[~2022-07-27 1:02 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-21 5:16 Volunteering to maintain ob-asymptote.el within Org Jarmo Hurri
2022-07-21 10:22 ` Munyoki Kilyungi
2022-07-22 7:28 ` Jarmo Hurri
2022-07-25 21:15 ` Munyoki Kilyungi
2022-07-25 21:15 ` Munyoki Kilyungi
2022-07-26 3:40 ` Greg Minshall
2022-07-26 9:52 ` Jarmo Hurri
2022-07-26 2:05 ` Ihor Radchenko
2022-07-26 10:09 ` Jarmo Hurri
2022-07-27 3:12 ` Ihor Radchenko
2022-07-27 3:13 ` Ihor Radchenko
2022-07-27 0:03 ` Tim Cross [this message]
2022-07-27 3:06 ` Ihor Radchenko
2022-07-27 4:09 ` Tim Cross
2022-08-18 16:04 ` Max Nikulin
2022-07-27 4:07 ` Jarmo Hurri
2022-09-01 7:52 ` Bastien
2022-09-03 13:25 ` Jarmo Hurri
2022-09-27 22:06 ` Bastien
2022-10-08 9:58 ` Jarmo Hurri
2022-11-09 6:21 ` Ihor Radchenko
2022-11-10 12:23 ` Jarmo Hurri
2022-11-13 4:27 ` Ihor Radchenko
2022-11-19 11:15 ` Bastien
2022-11-21 6:59 ` Jarmo Hurri
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 \
--in-reply-to=86fsinid4z.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=jarmo.hurri@iki.fi \
--cc=yantar92@gmail.com \
/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
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
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).