bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#8119: 24.0.50; `mark-active' needs its doc string


From: Drew Adams
Subject: bug#8119: 24.0.50; `mark-active' needs its doc string
Date: Sat, 26 Feb 2011 06:18:55 -0800

> > This is not the way bugs are handled - in any bug tracking 
> > system I've seen.
> 
> Well. That certainly is an opinion. I disagree.

OK, two opinions.  Do you know of a company where bug reports are retitled by
developers along the way, based on their current understanding of the underlying
problem?  Or are ever retitled, by developers or by anyone else?  I don't.  I
cannot imagine how a customer would look upon such a practice (wrt
customer-facing bugs).

Admittedly, the real identifier is the bug number.  And there is metadata for
categorizing bugs, which also helps to identify them.  But customers and others
often search or sort using titles and terms in titles.  User bug reports are
often expressed (including titled) in user terms, whereas the root problem is
often expressed in internal, implementation terms.

In my experience, the improved understanding that developers add to a bug report
gets added to the body (thread) or by recategorizing (metadata, merging etc.).
It does not happen in general by retitling.  What I see is that both the bug
number and the title remain as unchanged identifiers.  People might later refer
to a different bug number because of a merge, but the original number is not
changed - and similarly for titles.

So yes, my reply represents an opinion, but one that reflects pretty widespread
practice AFAICT.

> IMO the title is a brief phrase that best summarizes what the 
> real issue is.  This is for the convenience of developers in
> locating bugs to work on, and for other users in locating reports
> related to problems they may be having. The original title is not
> always the best summary of the real problem, which is why the
> retitle command exists.

The original title is not always the best summary of the real problem - agreed
100%.  But that's not the role of the title.  The title summarizes the OP's view
of the problem as originally reported - for better or worse.  And later
retitlings are not necessarily the best summary of the real problem either.

> But rest assured I won't interfere with any more of your 
> reports, at all.

Do what you feel you need to do, Glenn, but it's not about you, or me.  My reply
was an attempt to improve the process - just as yours was, no doubt.  As you
said, we have different opinions; that's all.  I think retitling for such a case
hurts more than helps; you don't agree.

That's not a reason to sulk or go off in a huff.  I appreciate your hard work,
as does everyone else.  My point was only about retitling - and it was not only
about bugs that I report.  It certainly was not personal.  No one is asking that
you take your marbles and go home.  I hope you will reconsider about helping on
bugs I submit, whether or not you reconsider wrt retitling bugs.

Think of my argument as a question, if you like: What is the policy wrt
retitling?  I gave an argument against it (in general) - I think it gets in the
way more than it helps.  Your reply gives an argument in support of it.  But
what is the policy?  When is it considered appropriate to use the `retitle'
command?






reply via email to

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