Re: Proposal for an Emacs User Survey

[Marcel Ventosa]

On Fri, 16 Oct 2020 17:04:22 +0300
Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 16.10.2020 16:45, Marcel Ventosa wrote:
> > On Fri, 16 Oct 2020 15:17:16 +0300
> > Dmitry Gutov <dgutov@yandex.ru> wrote:
> >   
> >> Do you think the "mockery" is entirely without merit?  
> > 
> > Yes, and I think mockery precludes understanding, particularly as we
> > are dealing with a thoughtful man and a well developed and time
> > tested philosophy, successfully put into practice against the odds.
> >  
> 
> Shutting our eyes to actual user behavior also precludes
> understanding.

From what I just read from Thibaut, a free software compatible solution
to replace MELPA is underway. Refusing to draw attention to something is
not "shutting our eyes".

> >> ignore a project that has done a lot to popularize Emacs over the
> >> years.  
> > 
> > I fail to understand the narrative that pushes popularity over all
> > else.  
> 
> Strawman.

I thought your argument was popularity, something that keeps coming up
in these kinds of discussions. What was your argument?

> > What would be the use of making Emacs the most popular editor if it
> > discarded the philosophy that brought it about?  
> 
> It doesn't.
> 
> And picking on 2-3 "ideologically impure" packages (out of several 
> thousands!) that are distributed on MELPA is counter-productive.

We could turn this argument around and ask why the developers who
maintain MELPA don't remove `2-3' packages that promote non-free
software. What came first, the GNU Emacs or the MELPA?

> >> I think it's both insulting to its developers, and stinks of
> >> thought police. Far from the idea of user freedom I hope to expect
> >> from GNU and FSF.  
> > 
> > You are conflating freedom, as in the freedom to do whatever you
> > want,  
> 
> I don't. But a certain freedom of thought, knowledge and discussion
> is necessary, as should be apparent to any educated individual.
> 
> > I don't understand how refusing to draw attention to a repository
> > that recommends proprietary software turns anyone into the "thought
> > police".  
> 
> It's a *survey*! A survey is supposed to gather insight into what
> users do, and what they need. Not shape their behavior.
> 
> You can't be effective at affecting change anyway, if you don't know 
> what's going on outside.

Indeed. As I recall, RMS suggested open questions instead of multiple
choice questions that "shape their behavior". With open questions, there
is no need to mention MELPA at all in fact. With open questions, the
insights that could be derived would be much more interesting.

> > Further up the list, I read RMS suggesting mentioning MELPA with a
> > disclaimer and warning about its use.  
> 
> That didn't seem to be the preferred option, in RMS's opinion.
> 
> > In fact, one of the most worrying aspects of this survey idea, as I
> > see it, is the suggested use of non-free Javascript to implement
> > it.  
> 
> Didn't Philip show a prototype that didn't use JavaScript?

That's very good news if the issue has been settled.

> >> it is unfortunate how Emacs leadership does little to follow the
> >> external, "unofficial" polls.  
> > 
> > What do you mean by this?  
> 
> I don't recall any single change in Emacs' behavior that resulted
> from an external poll or survey.

Why should Emacs development be guided by (external) survey results? I
would think it should be guided, for the most part, by what the people
putting their time into it want to create, within the principles of the
philosophy of the project and its goals. Also, anyone can suggest
changes and convince the maintainers that these changes are in the best
interest of the project (and contribute the actual changes if they are
accepted).

If they are not, Emacs makes it quite simple to implement changes for
personal "improvements". I have written functions that serve me
personally and change the behavior of Emacs to suit my needs. There are
limits to what I can do, which could be pushed if I dedicated a greater
effort to do so. How is that unfair?

If I thought one of my changes could benefit the community at large, I
would approach the maintainers and suggest it. If they disagreed with my
view, I could publish the code and could still share it with anyone
willing to run it.