ian martins <ia...@jhu.edu> writes:
> On Wed, Apr 21, 2021 at 3:45 PM Tim Cross <theophil...@gmail.com> wrote: > > Responding to essentially just flag you have seen the patch message > really only adds noise and may even 'drown out' those responses which > add real 'value' to any discussion. I also doubt that asking people to > do this would actually result in any actual change of behaviour by > subscribers. > > Timothy said there were 25 patches without response and the list goes back > six months, so we're only talking about 50 emails per year. That assumes there is a single 'owner' who accepts the responsibility to respond to every patch submitted. That isn't the situation with open source projects where people volunteer their time. Having someone respond to the author of a patch and provide some meaningful feedback would be great, but I don't see how that can happen in a project which is already stretched and with limited resources. There has already been multiple messages requesting additional help and for volunteers willing to put in the time needed to maintain parts of org mode. Adding to that workload isn't going to help. responses to patches really need to come from community members who are sufficiently interested in the patch to examine it or make comment on how useful they feel it would be. To some extent, if someone submits a patch and hears nothing, either they have failed to clearly explain what the patch does (and therefore did not tweak any interest) or it is a patch to introduce functionality which is of low interest to community participants. I think you can classify patches into 3 basic types - 1. Bug fixes. Patches which do not change functionality, but address bugs and performance bottlenecks in existing features. At present, this type of patch seems to get applied fairly quickly. 2. Patches which extend existing functionality. This type of patch requires significant consideration and evaluation. They can be time consuming to assess and a call needs to be made as to whether the additional complexity such enhancements add can justify the increased maintenance overhead such enhancements introduce. This is particularly challenging with org mode because org supports a diverse and sometimes complex range of workflows. Verifying an enhancement will not have adverse impact on some of these workflows is difficult and time consuming. Even apparently simple and straight-forward changes can have unexpected impact - consider for example the enhancement to support electric indent mode. This seemed fairly straight-forward and was a change which made org mode aligned with other Emacs modes and helps improve consistency withing Emacs across modes. However, it has had some adverse impact and caused some confusion because of how it interacts with existing org behaviour and configuration settings, such as with org indentation behaviour. 3. Patches which introduce new functionality. This type of patch also requires considerable resources to evaluate and adds to overall maintenance load. It is one thing to write an extension, but a completely different thing to maintain it over time. Even assessing the real demand for such extensions is challenging and time consuming and represents a significant demand on volunteers time. Asking volunteers to respond to patches of type 2 and 3 within some nominated time period is probably unreasonable. It also runs the danger of discouraging people from stepping up to volunteer to help maintain parts of org. This is why I think a better approach would be to provide more details and explanation on patch submission which can help set the expectations for the patch submitter and provide some guidance on what to do if they want to encourage/ask for feedback. This is also part of why I think patches of type 3 and possibly many type 2 patches should be initially released as separate 'add on' packages and made available via gitlab/github/melpa by the individual responsible for writing the patch. The author would then be able to see how useful/popular/desired their patch is, be able to ask for feedback and be able to get issue/bug reports to refine their work. This could be viewed as an 'incubator' like process. If such an enhancement/extension turns out to be very popular or demanded by the org community, it could then be migrated into either org core or the proposed org contrib package (by which time, it would likely be more mature and stable than it was when initially developed). It also has the advantage of not impacting existing org users who are not interested in the enhancement/extension. For an org user, little is more frustrating than an enhancement/extension which results in them having to either modify their workflow or update their often large repository of org documents. If we were to provide a detailed explanation on how to contribute bug fixes, enhancements and extensions on the worg site, contributors will know what is required, will be able to set their expectations in -line with how things work and have increased clarity regarding the structure of the org mode project etc. I would be willing to start drafting such a page if the community thought this would be worthwhile and be prepared to assist and assuming those responsible for maintenance agree. What I draft would be a starting point only and would require input to ensure it does represent what the community and maintainers believe is the right direction to take. -- Tim Cross
