Re: Idea for determining what users use

[Thien-Thi Nguyen <ttn@glug.org>]

   From: Richard Stallman <rms@gnu.org>
   Date: Wed, 28 May 2003 19:58:12 -0400

   I think you must have misunderstood the proposal.  We will insert
   these calls when and where we want them.  I can't see why we would
   have any problems as a result.

i deliberately widened the scope of my interpretation of the proposal
because such a facility is useful for all programmers in a similar
manner to how autoload.el, bytecomp.el and reporter.el facilities are
useful to third party programmers.

   Mail sent to emacs-features-used@gnu.org will just be dumped into a
   file.  We will search the file when we want to search it.

that is one way to do it.

   It is impossible to avoid this.  Whatever we put into the code,
   to indicate which functions etc. we are interested in,
   that thing will appear in certain Emacs releases and not others.

this presumes emacs maintainers are the only ones to make use of such a
facility.  that is fine, but i think a little forethought about the
mindset behind the initiative (to find out what is in actual use, i.e.,
to formalize one communication channel between users and programmers) is
valuable to making the design useful outside the scope of the code that
happens to be in the gnu cvs repo.

   Someone suggested "batching" these responses.  That can't be done
   because you never know that the same user will encounter another one
   of these calls.  The one he has encountered today may be the last one.

whether one hit or multiple hits, IMHO it is better to separate the
collection and reporting sub-activities, not only for efficiency but
also to support user control/privacy.

   It is also unnecessary, because these calls will be few and not
   frequent.  We will put them in features for which we don't know of
   any users.  Most users will not encounter any of them.  Of those who
   encounter one, most will never encounter another.

like any code, its frequency of use is really up to its users once it
gets into the wild.  in this case, the code in question is code to get
feedback on programs, so its users will likely be programmers interested
in getting feedback on their programs, the numbers of which are hardly
small and constantly growing (although not at a constant rate ;-).  that
is, although we apply the techniques extremely judiciously, you can't
trust programmers not to be extreme in unexpected directions...

   We know about surveys.  This is not a survey.

the intent may not not be to do a survey, but the components of this
idea share many aspects w/ those of a survey.  it differs from the
various surveys in the past in that the results are partially machine
generated.  perhaps it could be called an assay instead of a survey.

thi