From: Timothy <firstname.lastname@example.org> To: Eric S Fraga <email@example.com> Cc: firstname.lastname@example.org Subject: Re: Concerns about community contributor support Date: Tue, 20 Apr 2021 11:54:43 +0800 Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> 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 <email@example.com> 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.
next prev parent reply other threads:[~2021-04-20 3:55 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 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 [this message] 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://orgmode.org * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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
Org-mode mailing list This inbox may be cloned and mirrored by anyone: git clone --mirror https://orgmode.org/list/0 list/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 list list/ https://orgmode.org/list \ firstname.lastname@example.org public-inbox-index list Example config snippet for mirrors. Newsgroups are available over NNTP: nntp://news.yhetil.org/yhetil.emacs.orgmode nntp://news.gmane.io/gmane.emacs.orgmode AGPL code for this site: git clone https://public-inbox.org/public-inbox.git