Hi Eric,
Thanks for writing in and sharing your thoughts. I have some specific comments that you may find below, but more generally: I get the impression you approached this from the view of Org development and patch merging. In short, while I appreciate that Org development should be a considered process and that maintainer time is limited --- I think we could improve how well we communicate this to contributors, and maybe even our treatment of contributions. Eric S Fraga <e.fr...@ucl.ac.uk> writes: > Hello all, > > I've avoided saying anything in this discussion but not from lack of > empathy with the initial post. Many valid points have been made in the > thread and I understand the frustrations. My own view is that org is > now at a different stage than it was some years ago. It is a > feature-full package which generally works well for a very *large* set > of use cases. As a result, it is being used by many people and so is no > longer a niche product. I can't say I see how being used by a large number of people and growing beyond a niche product means that we can't set expectations for patches and/or responsiveness. Though I see you go in a slightly different direction below... > And, hence: > > On Saturday, 17 Apr 2021 at 23:29, Thomas S. Dye wrote: >> But, my sense is that patches to Org mode proper will continue to be >> adopted slowly and deliberately. > > and this is as it should be. I *rely* on org for my work these days. I > would not want the type of chaotic development we had in the early days, > development that would affect the stability of the package. New > features need to be considered very carefully. Indeed, but a lot don't seem considered, they just seem ignored. Particularly with a lack of communication, this can leave the contributor wondering whether they need to resend there email, bump it, wait for a particular maintainer to have a look at it, explain the intent further, etc. and I don't think leaving such uncertainty to grow is very nice. > But, also, as has also been said: the "maintainers" are volunteers and > do have other things to do. Stating that there is an expectation for > them to answer within a particular time frame is not fair. Maybe I'm not being entirely reasonable, but I would have thought something like "a cursory response within two months of submitting your patch" wouldn't be too hard to uphold; particularly when a cursory response could just be "we've been rather busy as of late, we'll get back to you on this in the future". > If there is a feature *you* need that is not there, the beauty of Emacs > is that you can have that feature, if you have implemented it, > regardless of whether it is accepted in the main org package. A large > part of my org environment is code that I have written myself to meet my > needs; my org specific config file is 3000 lines. Some bits along the > way have migrated into org or have informed org features but I can work > the way I want to or need to regardless of whether the features are in > the main code or in my own config. > > The excellent work that was done in creating version 9 (or maybe 8?) in > providing a wide range of hooks and filters means that practially > everything is customisable without requiring changes to org itself. > > And this leads back to the first point: I want org to exhibit a certain > level of stability now as otherwise much of my workflow would break. I > suspect many others have this same requirement. And the maintainers are > very good at avoiding breakage when new features are accepted but this > takes time to evaluate the impact of those new features. I too appreciate the versatility of elisp, and the way Org has been constructed that allow it to be modified so heavily by the end user --- I should know, I have ~4k lines of Org modification in my config. However, this does not preclude good ideas for Org modification being merged in. If I have a bugfix, or a very useful modification to Org, that's great for me, but it's good to share the improvement upstream. Isn't this a large part of the benefit of an open source development model? And when a patch does need to be carefully considered over a period of months or years, surely it's good to communicate that to the author instead of leaving them with silence? Please let me know what your thoughts are, Timothy.
