Plan for inquiries about Emacs changes

Plan for inquiries about Emacs changes

[Richard Stallman]

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

Here's the method I propose for inquiries (we used to call them "polls")
about users' views about possible changes in well-known behaviors.
Any comments or suggestions?


* Make a file for the replies to go into.

* Make a mailing address which drops all mail into the file.

* Write a inquiry statement which describes the proposed change in
sufficient detail that people can judge it, what kind of information
we seek, and where to email the response.  Include a deadline for
replies at least 6 weeks in the future.

If possible, we should tell users how to select various behaviors, so
that they can state their opinions based on comparing actual
experiences.

End the inquiry statement with the following text.

    We do not seek "votes", but rather understanding.  If you are for
    the change, please explain why.  Would it help you directly?  If
    so, in what scenarios?  How often, and how strongly, would it
    benefit you?  What would the benefit be?

    Or is it that you think it will improve Emacs, or speed Emacs
    development, by helping other users?  How so?

    Please distinguish between what you know and what you predict.

    Likewise, if you are against the change, please explain why.
    Would it inconvenience you directly?  If so, in what scenarios?
    How often, and how strongly, would it inconvenience you?  What
    would the inconvenience be?

    Or is it that you think it will harm Emacs or Emacs development by
    inconveniencing others?  How so?

    We invite you also to propose alterations in the proposed change that
    you think would improve it -- saying in what scenario that would be an
    improvement, and how so, etc.

    Please post the URL of this page in forums where it is appropriate,
    and resend it to Emacs users and mailing lists where you know people
    will be glad to receive it.

It is crucial to urge people repeatedly to explain their positions
because there is a strong tendency for people not to bother.

* Put the inquiry statement in a web page under gnu.org/software/emacs.

* Mail the inquiry statement info-gnu-emacs, help-gnu-emacs and
emacs-tangents, with the URL of the web page _and_ the full text
of the inquiry statement.

Also post a note referring to the web page on reddit.com/r/emacs, and
any other suitable places.  Mail the URL to Sacha Chua
<sacha@sachachua.com>.

* Wait until at least two weeks after the deadline, then study and
record the responses.  Note down all interesting comments, since they
are the most important information in the responses.

* Do count how many people support each position that people support,
but it would be a mistake to make the actual decision based simply on
counting.  A given change can affect one user very often, and affect
another user only rarely, but they could both state a "strong
preference".

* We are not compelled to choose between "make that change" and "no
change".  The best outcome of the inquiry is that the responses show
us how to design a way to please almost all users, almost all the
time, and not displease any user very much.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Plan for inquiries about Emacs changes

[Bastien]

Richard Stallman <rms@gnu.org> writes:

> Here's the method I propose for inquiries (we used to call them "polls")
> about users' views about possible changes in well-known behaviors.

I like the general approach, especially the fact that we
distinguish inquiries from mere "polls".

> Any comments or suggestions?
>
> * Make a file for the replies to go into.
>
> * Make a mailing address which drops all mail into the file.

If the two steps above can be easily done, why not.

Another way would be to have *someone* in charge of collecting and
editing the various feedback.  The role of this person could be
extended to providing summaries when asked for, and making sure
that the discussion does not stall.

Even when a fully automated feedback collection, having someone
helping with concluding the inquiry would help IMHO.

-- 
 Bastien

Re: Plan for inquiries about Emacs changes

[Dmitry Gutov]

On 25.05.2020 07:39, Richard Stallman wrote:
> * Make a file for the replies to go into.
> 
> * Make a mailing address which drops all mail into the file.

Will we have a procedure for doing this? Do we contact sysadmins every 
time we want to try this?

On the subject of the inquiry text, perhaps we should also add a warning 
that the responses will be available for the public to read.

Re: Plan for inquiries about Emacs changes

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 578 bytes --]

I think the basic idea is good.

My concern is that if we allow responses to bee too 'free form', collation
and analysis of the results will be too difficult and very resource
intensive. We might want to try and enforce a standard format for responses
to make collation of results easier. This could be done with a basic elisp
package put into ELPA (similar in principal to report-emacs-bug). The
package could even have an interface for submitting new proposals. It would
even be possible for the package to list currently open proposals etc.


-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 870 bytes --]

Re: Plan for inquiries about Emacs changes

[Richard Stallman]

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

  >  We might want to try and enforce a standard format for responses
  > to make collation of results easier.

All else being equal, that might not be a bad thing.  But it would
have the side effect of discouraging people from saying anything
which doesn't fit that form, and that is the opposite of what I
am trying to achieve.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Plan for inquiries about Emacs changes

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 1988 bytes --]

On Wed, 27 May 2020 at 13:07, Richard Stallman <rms@gnu.org> wrote:

> [[[ 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. ]]]
>
>   >  We might want to try and enforce a standard format for responses
>   > to make collation of results easier.
>
> All else being equal, that might not be a bad thing.  But it would
> have the side effect of discouraging people from saying anything
> which doesn't fit that form, and that is the opposite of what I
> am trying to achieve.
>

Yes, we would need to be careful to avoid that. I probably should have said
encourage rather than enforce. In my mind, I was thinking along the lines
of the template displayed when you submit an emacs bug report. In fact, the
more I think about it, the more I like the idea of having an ELPA package
which could list open 'enqiries', allow the user to review the content and
then respond. The response process could add additional meta-data that
could be used to route the response to the appropriate place and possibly
other information which might be useful in further automation or
processing. The user would then be presented with a buffer containing
something like a tempo template, which they then fill out with their
response. While people could delete the whole template and just enter free
form text, most probably wouldn't and those that do probably felt they
needed to for a reason, which could be valid.

It might take a few iterations to get right, but in the end, we could
potentially have a useful feedback mechanism built into Emacs that would
help gather opinions etc from a group wider than those on emacs-devel.  I
would certainly be willing to assist, but I don't think my elisp skills are
strong enough to do the initial design and implementation. Could certainly
help with testing, debugging etc.

-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 2566 bytes --]

Re: Plan for inquiries about Emacs changes

[Richard Stallman]

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

  > Will we have a procedure for doing this? Do we contact sysadmins every 
  > time we want to try this?

Several of us have accounts on fencepost.gnu.org and could do this
directly.

  > On the subject of the inquiry text, perhaps we should also add a warning 
  > that the responses will be available for the public to read.

In the past, we did not publish responses.  We could begin doing so,
but I don't see a need.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Plan for inquiries about Emacs changes

[Andreas Röhler]

On 25.05.20 06:39, Richard Stallman wrote:
> [[[ 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. ]]]
>
> Here's the method I propose for inquiries (we used to call them "polls")
> about users' views about possible changes in well-known behaviors.
> Any comments or suggestions?
>
>
> * Make a file for the replies to go into.
>
> * Make a mailing address which drops all mail into the file.
>
> * Write a inquiry statement which describes the proposed change in
> sufficient detail that people can judge it, what kind of information
> we seek, and where to email the response.  Include a deadline for
> replies at least 6 weeks in the future.
>
> If possible, we should tell users how to select various behaviors, so
> that they can state their opinions based on comparing actual
> experiences.
>
> End the inquiry statement with the following text.
>
>      We do not seek "votes", but rather understanding.  If you are for
>      the change, please explain why.  Would it help you directly?  If
>      so, in what scenarios?  How often, and how strongly, would it
>      benefit you?  What would the benefit be?
>
>      Or is it that you think it will improve Emacs, or speed Emacs
>      development, by helping other users?  How so?
>
>      Please distinguish between what you know and what you predict.
>
>      Likewise, if you are against the change, please explain why.
>      Would it inconvenience you directly?  If so, in what scenarios?
>      How often, and how strongly, would it inconvenience you?  What
>      would the inconvenience be?
>
>      Or is it that you think it will harm Emacs or Emacs development by
>      inconveniencing others?  How so?
>
>      We invite you also to propose alterations in the proposed change that
>      you think would improve it -- saying in what scenario that would be an
>      improvement, and how so, etc.
>
>      Please post the URL of this page in forums where it is appropriate,
>      and resend it to Emacs users and mailing lists where you know people
>      will be glad to receive it.
>
> It is crucial to urge people repeatedly to explain their positions
> because there is a strong tendency for people not to bother.
>
> * Put the inquiry statement in a web page under gnu.org/software/emacs.
>
> * Mail the inquiry statement info-gnu-emacs, help-gnu-emacs and
> emacs-tangents, with the URL of the web page _and_ the full text
> of the inquiry statement.
>
> Also post a note referring to the web page on reddit.com/r/emacs, and
> any other suitable places.  Mail the URL to Sacha Chua
> <sacha@sachachua.com>.
>
> * Wait until at least two weeks after the deadline, then study and
> record the responses.  Note down all interesting comments, since they
> are the most important information in the responses.
>
> * Do count how many people support each position that people support,
> but it would be a mistake to make the actual decision based simply on
> counting.  A given change can affect one user very often, and affect
> another user only rarely, but they could both state a "strong
> preference".
>
> * We are not compelled to choose between "make that change" and "no
> change".  The best outcome of the inquiry is that the responses show
> us how to design a way to please almost all users, almost all the
> time, and not displease any user very much.
>

What about implementing in a way Python language did:

https://www.python.org/dev/peps

Thanks,

Andreas