Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Ihor Radchenko <yantar92@gmail.com>]

> How about if we add a bug-reporting-function, to be set by any mode
> that wants to override the default one (which sends email to debbugs)?
> Then report-emacs-bug could be modified to detect the modes active in
> the buffer, and suggest the possible alternatives to the user.  I
> think adding to our coding conventions a single variable that in most
> cases doesn't even have to be set will be easier to propagate to the
> few modes which want their own bug-tracking.  And users will benefit
> from not having to search high and low for the relevant command.

This sounds reasonable. 

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Heerdegen <michael_heerdegen@web.de>
>> Date: Wed, 01 Jan 2020 02:19:42 +0100
>> Cc: ofv@wanadoo.es, larsi@gnus.org, emacs-devel@gnu.org,
>>  Ihor Radchenko <yantar92@gmail.com>, Dmitry Gutov <dgutov@yandex.ru>
>> 
>> | I am thinking if it would make sense to develop more standardised
>> | command name conventions for bug reporting and add them to
>> | (elisp)Emacs Lisp:Preparing Lisp code for distribution
>> |
>> | Then, the built-in emacs packages might be changed to follow those
>> | conventions and improve discoverability of bug reporting capabilities.
>> |
>> | Also, an information that different major modes may have they own bug
>> | reporting tools might be mentioned in the default template shown in
>> | report-emacs-bug.
>> |
>> | What do you think?
>> 
>> I think this is a problem that also confuses and discourages users to
>> make bug reports, so - any opinions?
>
> I don't really believe on relying on discoverability in this case.
> Even if users will discover the various commands, they might not know
> which one to invoke.
>
> How about if we add a bug-reporting-function, to be set by any mode
> that wants to override the default one (which sends email to debbugs)?
> Then report-emacs-bug could be modified to detect the modes active in
> the buffer, and suggest the possible alternatives to the user.  I
> think adding to our coding conventions a single variable that in most
> cases doesn't even have to be set will be easier to propagate to the
> few modes which want their own bug-tracking.  And users will benefit
> from not having to search high and low for the relevant command.

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China
Email: yantar92@gmail.com, ihor_radchenko@alumni.sutd.edu.sg