Re: bugs and bug tracking - Mailing list pgsql-hackers

On Tue, Oct  6, 2015 at 01:05:24PM +0000, Nathan Wagner wrote:
> So, in order to do some clean up and see how my pgbugs page
> (https://granicus.if.org/pgbugs/) might actually work I've been going
> through bugs and marking their status.  A lot of questions arise.
> 
> A lot of the reports aren't bugs at all, but requests for help.  My
> guess is that the users either don't know where to ask or don't
> understand the difference between a bug and not knowing how to do what
> they want to do.  Perhaps a more thorough explanation on the submission
> form would be useful.

I am glad you are putting together a mock-up solution with actual data
so we can see what a final solution would look like, and see some of the
decisions we have to make.

First, let me say I am glad we are talking about this, and am open to
the criticism that my and other's tracking open items by keeping them in
our personal mailboxes is not only odd, but bizarre given the size of
our community and the responsibility we have.

I do think we rushed to choose a tracker a little too quickly.  Let me
explain, from a high level, what a new tracker will change in our
workflow.  Right now, items stream at us via email.  They are broadcast
to everyone on the lists.  For most people, the email just flies by and
is deleted.  For a few people, they respond, and generate more activity.
For a few others, they keep the email to see if is resolved, and if not,
try to get it resolved later, or recorded.

Therefore, our current default behavior is to ignore user reports,
unless someone takes an action to reply, record, or retain the email for
later review.  What a tracker does is to make the default user report be
_retained_, meaning we have to take action to _not_ retain a user report
as an open item.

This gets to the core issue --- that maintaining a tracker is going to
require more work than what we do now, and explains why most community
project trackers (and perhaps most commercial project trackers) become
clogged with unaddressed items.  This also highlights the need for a
serious dedication of time to keep a tracker orderly.  This is perhaps
best expressed by this comment from Andrew Dunstan:
http://www.postgresql.org/message-id/560D4960.5010401@dunslane.netIn my former life I once had to send out a memo to
developersthatsaid "If you're not working on items in the tracker you'renot doing your job."
 

In summary, a tracker can become an unrelenting task-master, where you
are continually un-retaining items and reclassifying, which might
explain why they often end up disorderly or ignored.  There are
advantages to having a tracker, but it will take action on our part to
manage the new default-retain behavior.  I think this is why email
integration is key, because it allows us to adjust the retain behavior
with minimal effort.

Second, we have a mix of user reports.  Some bug reports are not bugs
and must be reclassified.  In other cases, uses ask questions via
non-tracked communicate channels, e.g. pgsql-general, but they are
really bugs.  So, to do this right, we need a way of marking tracked
bugs as not bugs, and a way of adding bugs that were reported in a
non-tracked manner.

One of the advantages of the non-retain behavior we have now is that,
for responsible developers, a recognized bug either has to be recorded
or fixed --- both take time, so we have a tendency to choose "fix". 
With a retain-default behavior, "recorded" becomes the default and the
pressure to fix is reduced.  Of course, there is also the "let it fly by
and ignore it option", which we have now, and which we will not have in
the default-retain mode.

My point is that we have our current workflow not because we are idiots,
but because it fit our workflow and resources best.  I am not sure if we
have succeeded because of our current non-retain mode, or in spite of
it.  It might be time to switch to a default-retain mode, especially
since most other projects have that mode, but we should be clear what we
are getting into.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription                             +