Re: [Emacspeak] Binary Builds (via Github)

[Tim Cross <theophilusx@xxxxxxxxx>]

I don't think increased user support requests in themselves are the
key issue. Raman (and others) have been happy to help users that are
willing to help themselves. However, the big issue is that as you add
these additional bits of functionality or features to make it easier to
get started, you add both additional maintenance and often additional
complexity and higher expectations, which by their nature reduces the software's usability as a
research workbench because new ideas and prototyping take longer. This
is a key part of Kent Beck's 3X model, You cannot have both. You may be
able to seek a middle ground, but that takes some real discipline and a
willingness to say no even when there seems to be community demand. I
think Raman is successful in finding that middle ground.

The work Robert has been doing is absolutely fantastic. However, we need
to also balance what he is doing with the long term goals and
maintenance demands going forward. I know from my own open source
projects that contributions can easily become an issue as well as a
benefit. For example, I added functionality to my JS library which
people wanted and which was originally contributed via a PR. However,
some months later, the original contributors moved on to other things
and now I'm left having to maintain functionality I didn't want but
which is now expected by the user base. I now have a larger maintenance
burden than I originally wanted and have to spend time maintaining
something I don't need which is taking time away from the stuff I do
want to do. 

Victor Tsaran <vtsaran@xxxxxxxxx> writes:

> My personal take is that we can have both. I don't think it has to be one or the other. :)
> I am largely comfortable with the way Emacspeak works today, but I would be equally glad if Robert's work can attract
> younger users who did not grow up in the age of Unix shells and such.
> I can only admire Robert for his willingness to dedicate his time and energy to make Emacspeak more approachable!
> Raman is correct though that any such user-friendly improvement may lead to an increased number of customer support
> requests. :)
> But then again, perhaps not!
> :)
>
> On Wed, Apr 24, 2024 at 4:46 PM Tim Cross <emacspeak@xxxxxxxxxxxxx> wrote:
>
>  I think the below statement from Raman is one which we, the emacspeak
>  community, should note and consider. My own personal view on Emacspeak
>  is that it is philosophically very different to most other packages out
>  there, especially end user focused ones. Understanding this
>  philosophical difference can be important as it helps ensure alignment
>  between expectations and reality, which is a fundamental component of
>  good mental health.
>
>  I think of emacspeak as Raman's research workbench which he has made
>  available to those who would like to use it. As such, I expect a system
>  which is to some extent constantly in flux. I have no expectation
>  regarding API stability, backwards compatibility or user support. I
>  expect it will be necessary for me to investigate and resolve any issues
>  I run into. I might ask for guidance or I might report an issue to see
>  if anyone else has encountered something similar, but over all, I expect
>  it is down to me to find a solution. I see my relationship with
>  emacspeak as largely a symbiotic one. By using it, I get to experience
>  the implementation of many of Raman's ideas regarding an auditory
>  interface e.g. soundscapes, auditory icons, voice locking, spacial sound
>  etc. In return, Raman gets feedback from users and important data points
>  regarding various ideas, both from his daily usage and that of community
>  users. In many respects, I find it beneficial to think of emacspeak as a
>  prototype rather than a user package. It can be a little unstable, it is
>  often a bit rough around the edges and can occasionally be a little
>  annoying. However, often it enables me to do things that were near
>  impossible with other solutions and often it surprises me with some new
>  idea, concept or feature and above all, it enables me to work at a
>  productivity level which was not possible with other solutions.  
>
>  I think Ken Bech's 3X model is quite relevant here. In this model, you
>  have 3 stages explore, expand and extract. Each stage is typified by
>  different characteristics.
>
>  - Explore: This is the R&D stage. This is where I see Emacspeak as
>    sitting. The focus here is on rapid prototyping of ideas which takes
>    preference over stability and maintenance.
>
>  - Expand: This is the performance tuning stage. You focus on how to make
>    the solution perform well under load. There is little new idea
>    experimentation. Instead, you focus on improving the performance of
>    what you have.
>
>  - Extract: This is the final 'product'. The focus is on stability,
>    maintenance and maximising return on investment. This is the user
>    level product. 
>
>  Understanding emacspeak is permanently in the explore stage will help in
>  understanding what Raman's priorities are and why it is so important to
>  keep a focus on research rather than maintenance and why adding
>  functionality which might improve the end user experience needs to be
>  balanced against the potential negative impact on being able to try out
>  new ideas and implement prototypes.
>
>  When I first came to emacspeak, I found the focus on research and
>  possible consequences regarding stability a concern. Initially, I seemed
>  to be running into issues every other day and I seriously considered
>  forking the project and creating a version which focused on end user
>  usability and stability. However, as my knowledge of Emacs, Elisp and
>  emacspeak increased, this became much less of an issue. The reality is,
>  while it may be challenging to get started, once you are started,
>  maintenance is trivial. I soon realised that the effort to maintain a
>  'user version' of emacspeak simply wasn't worth it. 
>
>  > For me,Emacspeak is both my daily tool and also a research work-bench
>  > of sorts, and I am  therefore very careful to not turn into a mode
>  > where I'm just maintaining a set of bla tools and end up stuck in a
>  > least common denominator state . 
>  Emacspeak discussion list -- emacspeak@xxxxxxxxxxxxx
>  To unsubscribe send email to:
>  emacspeak-request@xxxxxxxxxxxxx with a subject of: unsubscribe