RE: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Drew Adams <drew.adams@oracle.com>]

>   > 1. There's an option that lets you choose which
>   >    fields to include by default, when reporting
>   >    a bug: `ebp-report-emacs-bug-included-fields'.
> 
> This would be extra complication, the opposite of what we want in
> general.

Why?  What we have now is no possibility to express
your preference of what to include (by default).

With the option, if a user does nothing, she gets
just what she gets now: everything included.  Easy.

All the option does is let you, a user, decide what
to include by default, should you want to do that.

What's the complication?  Certainly there's nothing
complicated for a user.  Who's life is complicated
by giving users such a choice?

> The specific problem here is that report-emacs-bug includes data that
> might be sensitive.

The specific problem is that it includes data that
some users might not want to send - for whatever
reason.

And it does so systematically.  The only recourse
for a user is to manually delete whatever info she
doesn't want to send - each time, for each bug
report.  How is that helpful to users?

> It would be good to remind people that they don't
> have to send that data,

And to tell them what all that data is - the various
fields/sources.

And to show them where it is (especially because the
buffer does not make very clear which text gets sent
and which does not (boilerplate instructions/help).
Identify the data - point it out.

> and help them avoid it if/when they want to.

There's currently no way to "avoid" inclusion of
any of the text.  Users can only delete it manually
before sending the message.

Avoiding would prevent inclusion in the first place.
All we have is after-the-fact, on-demand deletion.

> But let's do that in the simplest possible way.

The simplest way is to not make the user do anything,
to send everything - like now.

But to also let a user state her general preference.
Let her decide what the default behavior is.  Not
that every user has to do that, or will want to do
that, but that any user can.

Alternatives that just point out the fields, or even
provide easy ways to delete them, still make users
to do that manually.  And each time, for each report.

How is that simpler and safer for users?

> I think the simplest possible way is to identify the data that might
> be sensitive, and help users exclude all that data.

The best way to help users exclude any data they
might want to exclude, by default, is to provide an
option that lets them do just that: set their own
preferred behavior.

What's complicated is making a complicated issue
out of this.  There's a simple solution that has no
effect on any user who doesn't care, and that lets
any user who does care get exactly the behavior she
wants, by default, and that lets her override her
own default for any given report.