Ihor Radchenko <yanta...@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.
