Re: Concerns about community contributor support

[Tim Cross <theophilusx@gmail.com>]

Timothy <tecosaur@gmail.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>> This is a common development path for a successful project. Kent Beck
>> (extreme/agile development) has been focusing a bit on this with his 3x
>> development model (eXplore, eXpand, eXtract). (see
>> https://medium.com/@kentbeck_7670/fast-slow-in-3x-explore-expand-extract-6d4c94a7539).
>> To some extent, we are in an expand/extract stage for org mode. Focus is
>> on addressing performance and extracting core functionality - new
>> 'features' need to demonstrate a high level of 'return on investment'.
>> At this stage, enhancing or extending the functionality is a slower and
>> more cautious process which requires greater justification than was
>> common in the 'explore' stage.
>
> Interesting link, thanks. Org being in the expand/extract stage
> certainly rings true to me from my exposure.
>
> That said, I don't see why being in this stage of development means we
> don't need to acknowledge people's attempted contributions.
>

This is probably just a reflection of how a largely community driven
approach works. There isn't really anyone with a responsibility to
respond or reply to a patch within some acceptable 'time'. There is a
very limited number of people who have commit rights and who do apply
patches etc. At this time, priority appears to be given to patches which
fix existing behaviour (bug fixes) over ones which extend or modify
existing behaviour (enhancements and new features). 

I suspect the level of response something receives is a reflection of
the level of relevance or interest to others on the list. Personally, I
don't respond to messages which either

- Don't have relevance to how I use org mode. 

- I don't understand the objective or reason/rationale. 

- I don't agree or believe the idea is a good one. Sometimes I will reply
  if I feel (very subjective) the idea would have negative consequences
  in general or I think there is a simpler alternative solution.
  However, often I will take a wait and see approach before contributing
  anything. 

> My concern is centred around the lack of /response/ to people sending
> in patches. Radio silence for *six months* after sending in a
> contribution seems ridiculous to me.
>

I don't think it is ridiculous. I think it is more a reflection of how
less formal and structured approaches work. I can understand why someone
who has put in the effort to create and submit a patch would appreciate
some feedback, but I'm not sure an expectation or desire for feedback is
sufficient.

Personally, I feel that if you make a patch submission, you sometimes
need to 'sell' the patch. This is especially true if the patch is not a
basic bug fix. Having developed a patch, it is easy to become very close
to it and assume aspects of the patch or what it is proposing are self
evident. It can be challenging to put yourself in the shoes of someone
encountering the patch for the first time and consider how your
submission will come across. Simply submitting the patch and expecting
feedback may not be sufficient and followup posts will be required to
either clarify, remind or encourage feedback. 

> This is an interesting thought. Putting aside the fact that this is
> somewhat tangential to points I wished to discuss, I have a number of
> reservations:
> + Many patches are modifying core functionality, and would not be
>   suitable as an add-on (e.g. [1], [2], [3], and more)

There is no limit on what additional external 'add on' packages can do.
They can easily modify core functionality. This is one of the core
benefits/strengths of lisp languages. I can redefine a core function in
my add on package and provided my package is loaded after the core, my
redefined version of the function will be what is executed when the core
uses that function. For example, I have a heavily 'patched' version of
org mode, but I never actually change the core org code. Instead, I have
my own org configuration which redefines and modifies core functionality
which I wanted changed to suit my requirements.

I'm not totally clear about what sort of acknowledgement you want/expect
for patch submissions. I get the impression it is more than a simple
"thank you for your patch" and rather more detailed review/feedback of
your patch. For the latter case, it is likely more a reflection of
available resources - in particular, people with the necessary elisp
skill to be able to review and provide valid feedback and available time
for those limited resources. My observation, which is just one view, is
that bug fixes get priority and other patches get attention based on a
combination of community interest, available time and the 'squeaky
wheel' principal. This relates to my point about needing to 'sell' your
patch. For example, I had a quick look at some of the patches you
referenced. None of them had any relevance to my use of org mode and
none of them involved org functionality I am familiar with (from an
internals perspective), which means I am not in a position to comment.  

> + This feels like it could become a bit of a graveyard of ideas.

Yes, that is possible. However, I'm not sure that is necessarily a bad
thing. My experience with software development is that around 80% of
ideas never survive. This is partly why it is so important during the
'explore' stage of development to allow/support the rapid addition and
implementation of new ideas. Ideas which seem good on the surface can
often turn out to be less beneficial in reality or have unforeseen
negative consequences which only become evident with broader use.

It is survival of the fittest. Ideas which are really good, which
satisfy a common use case and which avoid adverse impact tend to
survive. Sometimes, this does mean a good idea fails because it wasn't
the right time, it wasn't presented clearly or understood or because it
needed more refinement or additional features/functionality which
doesn't yet exist.

> + Many patches aren't even being acknowledged. Given this, I am highly
>   suspicious that good additions will actually be moved into Org.

This depends on a lot of factors - assignment of copyright, quality of
code, type of addition, community desire for addition etc. My personal
perspective is that we should actively discourage further additions or
extensions to org mode and instead focus on making org mode itself a
core, clear and well documented and maintained mode of common basic
functionality and have external packages which take that common
functionality and wrap/customize/extend it to provide more high-level
functionality. I think it is a mistake to try and make core org-mode
everything to everyone.

I use org mode a lot - daily and it is linked into almost every workflow
I have. However, the actual org mode features I use are quite limited.
For example, I don't publish web sites with org mode or use it to
generate gnuplot graphs or code python blocks. I also don't want
additions, extensions or enhancements to publishing, generation of
gnuplot graphs or enhancements to python source block handling to impact,
alter or otherwise affect what I do. However, every time you modify the
core org-mode package, this potential exists. 

> + This complicates the development model.

I actually feel it would make things clearer. Development of org-mode
itself would focus on bug fixes api refinement and performance
improvements. Everything else would depend on add on packages, which
might adopt completely different development models. 

Like with most things, there are pros and cons. This reply is already
far too long, so I won't go into further detail.

To avoid confusion, I'm not suggesting all is fine and perfect. There is
always room for improvement. However, we need to work within the
resource constraints we have and adjust our expectations to be within
those constraints. We can probably do better with expectation management
and perhaps some more details on worg would be helpful wrt contributing,
acknowledgement and feedback. Maintaining a community takes effort,
especially a community with the diverse backgrounds, languages, cultures
and different social norms as this one. Getting the right balance is
challenging.

While it is good to raise and identify areas we may be failing in or
which need improvement, we also need to try and identify viable
solutions. Along these lines, I wonder if it would be worth having a
section on worg for non-bugfix patches where the community could provide
feedback. This could be as simple as basic "I think this is a good/bad
idea" to more structured feedback, such as code review etc. Personally,
I'd like it if we had something like gitlab (not github) which would
make it easier for people to add/review patches. However, even this
requires resources to maintain. 

--
Tim Cross