[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal for an Emacs User Survey

From: Jean Louis
Subject: Re: Proposal for an Emacs User Survey
Date: Sun, 11 Oct 2020 13:46:27 +0300
User-agent: Mutt/1.14.0 (2020-05-02)

* Philip K. <philipk@posteo.net> [2020-10-10 12:37]:
> Richard Stallman <rms@gnu.org> writes:
> > [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> > [[[ whether defending the US Constitution against all enemies,     ]]]
> > [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> >
> >   > The most obvious reason to me is that user error handling is pretty
> >   > poor. Because there is no JS, we cannot offer front-end validation, that
> >   > means that the backend server is responsible for validating fields
> >   > submitted.
> >
> > If we want to learn what users think, we should not limit their
> > responses to a small set of 'valid" possible answers.  The plan
> > I designed for inquiries asks users to answer in their own words.
> But wouldn't that make it needlessly hard to analyse the results,
> especially if the question should be numerically quantified?

As I have done larger surveys for public relations and I know methods,
I know how tedious it is to evaluate such survey, we have been
employing many people, like 20 people, to just analyze what exactly
did people check or did not check, what did they write, to read their
handwriting, and then to properly analyze it.

However, Emacs feature requests or survey about using Emacs need live
user, not user as a number.

> I get the value of plain text responses, but recognizing that the
> answer to the question "how long have you been using emacs", could
> result in:
> - "Since 1996"
> - "24 Years"
> - "January 1996"
> - "Around the second time Clinton got sworn into office"
> - "1896" (but actually a typo)
> All of these basically mean the same, but the effort to recognize this
> automatically (which would be necessary, if you want to see how factors
> correlate) would not be worth it.

It is better not to do it automatically.

Emacs is developed through number of developers, they are not doing
development automatically, they are well coordinating and
collaborating with each other.

Any user who is sending a request is also collaborating in such
development by proposing features or telling about dislikes, telling
their opinion.

Those users are valuable, their answers should not remain as numbers
on the paper, or communication that comes only one time.

Kind answer on their email or requests, likes or dislikes, will
involve users into collaboration and coordination and better
understanding of what such users were thinking.

We already have mailing lists for Emacs, but we do not have it well
integrated into Emacs, that users can find out about it.

So I am proposing to follow the friendly GNU Hyperbole
https://www.gnu.org/s/hyperbole example, where
Bob Weiner have implemented Hyperbole menu, from which every user is
enabled to subscribe to Hyperbole mailing list or to send email to
Hyperbole mailing list.

Thus menu item like "Tell us how to improve Emacs?" in Help menu could
be the initiation to such collaboration.

And I think that many Emacs users do not use Emacs to send email, so
there shall be option by using eww, to send a form, and form can be
already packaged with Emacs.

Thus user could decide to:

- subscribe to improvement mailing list

- send email with or without subscription, just as almost any GNU

- unsubscribe

- or send a WWW form, by using eww function

The form would be in HTML format, accessible to eww easily.

Over time, the form could be improved or changed in new versions.

It could include free field to write what one wants, or it could
include set of question as well.

Now this opens the question that the other mailing list,
help-gnu-emacs should also be integrated in the menu, just as the user

I recommend everybody to install hyperbole package and to see how it
was implemented, it gives incentive to user to collaborate and
coordinate, and if it would not be implemented in the menu, user would
hardly find the mailing list.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]