Re: Proposal for an Emacs User Survey

[Dmitry Gutov]

On 16.10.2020 17:33, Marcel Ventosa wrote:

> > 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".

To make a replacement for something, you need to know what something is, 
and why it exists.

> > > > 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?

You made a strawman claiming that I somehow push popularity "over all else".

My argument is that they have done a lot for the community. Some of 
those effects reach the core too.

> > 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?

No, we couldn't "turn this argument around". Those statements are not 
even remotely on the same level.

Some Emacs maintainers themselves are known to use proprietary software. 
And use Emacs on proprietary OSes. And yet, somehow, MELPA is the odd 
one out?

> > 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.

So we won't suggest ELPA as an option either? What about the users who 
don't know the difference? MELPA is also an ELPA, after all (as in 
"Emacs Lisp Package Archive").

> > Didn't Philip show a prototype that didn't use JavaScript?
>
> That's very good news if the issue has been settled.

It's solvable, let's put it this way.

> > > > 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?

Why should it use the scientific method? Why should it pay attention to 
other people, or the world at large? Is that what you're asking?

> 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.

It's not a painting or a novel. It's a software project, with certain 
expectations of practicality.

> 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).

No, not "anyone can convince".

And like I said: no attention to external polls. Which is what you asked 
me to clarify.

> 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?

You're veering the discussion off to the side for some reason.

But if we're talking of "unfair", releasing Emacs under GPL, enabling 
such excellent extensibility that multiple communities spring up over 
years, ones brimming with creativity and people dedicating years of 
their spare time to the extensions, and then badmouthing them from afar 
as though they violated some existing contract (social or legal), *that* 
is unfair.