
How not to handle open source feedback - ColinWright
http://www.jacquesmattheij.com/How+not+to+handle+open+source+feedback
======
avar
I've had a bunch of my valid bug reports closed by Ubuntu. I've switched to
Debian, and every one of them is being closed unless I go and reproduce the
issue again in later versions of Ubuntu.

Some of them are general issues that won't have been fixed in later versions.

~~~
Luyt
jwz wrote on this:

<http://www.jwz.org/doc/cadt.html>

 _"This is, I think, the most common way for my bug reports to open source
software projects to ever become closed. I report bugs; they go unread for a
year, sometimes two; and then (surprise!) that module is rewritten from
scratch -- and the new maintainer can't be bothered to check whether his new
version has actually solved any of the known problems that existed in the
previous version. "_

~~~
j_baker
What's most annoying is the combination of this issue and the one the author
writes about: the ticket sits around for a year and then gets closed a year
later for some silly reason (like lack of a test program).

------
click170
I can understand why some projects close bugs due to inactivity, but I was a
little surprised to see that it was closed after only a month of idling.

Asking for a code sample test case in this instance is inappropriate, and IMHO
is a lazy shirk of one's responsibilities. Sure, if I can't reproduce the bug
I'll ask for a test case, but in this situation it was not called for. That's
certainly not how I'd treat a user who cared enough to submit a bug in one of
my programs.

------
MatthewPhillips
I've worked on projects in the past where emphasis in placed on closing bugs,
not fixing them, so this is not a surprise to me.

------
tszming
Another example of poor bug handling (although FB is definitely not open):
<http://bugs.developers.facebook.net/show_bug.cgi?id=16580>

This bug was wrongly closed, but when a bug is closed in their system, you
cannot re-open it.

------
mihaifm
Sadly bug fixing in corporations is all about closing tickets.

~~~
sixtofour
"If you're maintaining an open source product that is meant for mainstream
distribution then please do not do this, fixing bugs is not about closing
tickets, it is about improving a product."

MySql is an open source project, but Oracle is not an open source
organization, it's the biggest of BigCorps, with performance reviews, raises,
360s and for all I know 720s. I'm sure that bugs closed is someone's
performance metric, and as we know, that which gets measured gets done.

------
jmathai
Ah, the game of hot potato. The reporter ended with it. The person asking for
a test case wins.

------
wccrawford
I never ask for code to prove a bug unless I can't replicate it myself. (On
the other hand, if I submit a bug, I almost always provide code before being
asked.)

In this case, though... It seems only 1 person has experienced this, and
didn't care enough to even reply back. Closing it due to inactivity doesn't
seem to be wrong, to me.

~~~
dlikhten
There was no indication that any info was even sent to the user, for all he
knows all was fine (and still is) just unresolved. He did his job and reported
the bug in detail, oracle needs to do their job and reach out to him. Can it
be reproduced? More info needed? Etc. You don't ask for test cases unless its
really problematic or the dev can't figure out whats wrong in your opinion.

~~~
wccrawford
Most bug-trackers automatically send notices if the user has put in valid
contact info. If they didn't, or opted out of the notices, then they'll see
the message when they check it for updates.

If they never check it again, time is definitely better spent somewhere else.

------
ddelony
Many eyes make bugs shallow, because they simply ignore them.

------
jrockway
Click the fork button. People that release free software have no obligation to
their users; they wrote some code, made it available, and that is that. That's
all free software is about: instead of being at the mercy of some Supreme
Entity that makes your software, you have the power to do anything that
Supreme Entity does. Fix the bug. Pay someone to fix the bug. Write your own
database, and include the parts of MySQL that you like.

People who dedicate their time and money to hosting free software are not the
ones to blame for your problems. Yup, they made a fucking dumb coding error
that's costing you millions of dollars a second. But that's your problem, not
theirs. All they did was share their creative work for your enjoyment; if you
don't enjoy it, it's your problem.

As free software becomes more popular, people are forgetting what it means. It
means that everyone has the same opportunity as the original author to fix
stuff and freely share their fixes. It doesn't mean that the author has to do
whatever you tell them to.

~~~
starpilot

      It doesn't mean that the author has to do whatever you tell them to.
    

Right. Likewise, you're not obligated to help people pick things up or hold
doors open for people. But you do it because it's a reasonable response. The
maintainer had the right to respond how he did, that doesn't mean he _should
have_ , if he was interested in building rapport with the community, or
improving the product. (This is sort of how companies have the right to
provide poor customer service, but may prefer to yield that right even at
added costs.) This is about bug reporting etiquette and the fact that being
uptight about code sample procedures may be in bounds, but also
counterproductive.

------
inkel
MySQL people should see the following keynote: Being Your Best Asset and Not
Your Worst Enemy - [http://confreaks.net/videos/350-gogaruco2010-being-your-
best...](http://confreaks.net/videos/350-gogaruco2010-being-your-best-asset-
and-not-your-worst-enemy)

------
code_duck
Not just bugs, and not just technical issues: don't deal with reports from the
community about problems with _any part_ of your service like this.

------
exDM69
I'm gonna get downvoted for this, but... Am I the only one who disagrees? To
me this post should be titled "How not to file a bug for an open source
project"·

A good bug report should include:

\- A reproducible test case - ALWAYS

\- Expected output and failed output

\- The exact version of the software in question (preferably git commit hash
or equivalent). "Whatever shipped with ubuntu 9.04" is not a version number.

\- This is optional: A patch to fix the issue

In this case the patch should have also included objdump (or similar) dumps of
the libraries the author has and a list of all functions exported that should
not be (e.g. everything not ^mysql_.*).

Although this bug report is valid and describes a real issue, it has to be
manually confirmed as an issue by a dev. This will take 5 or so minutes, which
is too long to handle any significant volume of bug reports.

I'm sure MySQL/Oracle has commercial support available if you need service. If
you need help from the open source community you need to be a part of the
community and do your part of the job - you're not a paying customer. A well
reported bug is a half fixed bug.

------
dustingetz
in a vaccuum, yes, every codebase should be perfect and every bug should be
addressed. in real life, the codebase is aligned with the business needs of
the maintainers. mysql's codebase may be sloppy, but nobody else seems to care
about this particular issue, and if they do it will be +1'd until it gets
fixed.

~~~
Yhippa
From the perspective of the MySQL developers this may be the only way to
handle feedback. If a lot of people use your software you're probably going to
get a significant amount of bug reports.

If I'm in the shoes of the MySQL bug triage team you have many things to do:
research important bugs, relay them to the development team or internal
stakeholder, and to consolidate bugs. I don't know the details but user bug
reports might be like drinking out of a fire hose and the current process of
asking for more specifics and timing-out bug reports may be their personal way
of handling them.

~~~
Joeri
I don't think just closing bugs without a solution is ever acceptable. The
end-goal is increasing user satisfaction with your software. If you close a
bug without resolution, you're not satisfying users. Closing this bug they way
they did only improves some QA benchmarks, it doesn't actually satisfy any
users.

