Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By icenogle on
As a software engineer, I find it very odd, when someone logs a bug, for someone else to say, "Well, gee, I don't experience that, so you must be wrong." Software bugs are like that -- if they happened all the time for everyone, it's likely the developer would have found it first. Bugs usually result from boundary conditions -- circumstances which occur infrequently because they represent some kind of extreme -- and by definition, most of us drive down the middle of the road.
The next level of inappropriateness is to try to decide democratically whether a bug is actually a bug. So people keep piling on -- "I don't see that, either" -- until someone declares victory, because only one or two people actually see the problem, whereas a whole raft of people don't. People who drive down the middle of the road will always outnumber the pedestrians on the shoulder.
The final mistake is to change the state of a bug to a support request, or shift it to someone else's project, because you don't experience it -- especially when anecdotes of similar buggy behavior keep cropping up. It's like pulling the batteries out of a carbon monoxide detector because it's annoying, and it only goes off occasionally.
These things happen here all the time. As users, we are told incessantly (but appropriately) to search the database before filing a bug or support request. What one often finds when searching is not one thread on the subject, but many. Very often, those threads are curtailed by people who autocratically declare the issue dead, "because I don't experience the problem, and I have been using this for a long time." A short time later, someone else sees the same problem, and running across the closed issue, opens another one.
This effectively prevents these individual anecdotes from being collected together in one place. Bugs are often solved by seeing which possible causes have been explored and which ones haven't; which variables are different, and which ones are the same, across different experiences of the bug.
The fact that YOU haven't experienced the bug is most often because you, as most people, are faithful to your patterns of work, and those patterns don't include the circumstances that produce the bug. If you think that your way of doing work is the right way, and someone else's isn't worth addressing, well... you're beyond contempt.
Bugs are solved most effectively with the scientific method. A bug is experienced; an hypothesis is put forward for how/why the bug occurs; an experiment is designed to test the hypothesis, so that it is either confirmed or discarded, etc. All kinds of people weighing in with "I don't see the problem" are just adding noise to the process, and not any useful information.
I won't even get into the rudeness problem, where people flat tell you to get lost if they don't experience or sympathize with your problem.
How 'bout we work on changing this? It would be a real boon to open source.
Comments
There was a module where
There was a module where lots of people faced a particular issue, but the developer couldn't reproduce the same bug despite trying many times and despite asking the people for the related variables. This went on and on, one fix was submitted, but it didn't work and the developer could only finally fix the issue when I offered full access to my server. It was a matter of minutes before the bug was spotted and fixed.
Of course, I don't suppose all drupal users will go about offering full server access to the developer (that is a matter of personal trust between the user and the developer), nor do they need to- some users are very smart enough to figure out the issue themselves.
My point? Just that when developers say they can't reproduce the bug, it may not be that they are being autocratic but simply stating the facts. This is not a defence of the developers or to say that your post does not have valid points. I am just offering my experience for discussion.
Yes, of course. A developer
Yes, of course. A developer who says "I don't experience this but if someone can help me reproduce it I'll try to fix it" is doing the right thing. Point taken.
However, my rant was finally precipitated by a developer who closed a bug because he didn't experience it, in spite of there being other threads from other contexts, which he obviously wasn't aware of, pointing to the same problem.
I think there are people doing open source development who simply haven't thought about these things, or been exposed to professional practice. Such people, like junior engineers, are often defensive about bugs, and think of them as indictments of their work. They haven't thought dispassionately about the origins of bugs or how they are most effectively squashed. This is just a heads-up to those people.
D Icenogle
ayup
three weeks ago i started submitting bugs. with patches.
i'm now keeping my patches on my blog. if anyone one wants them, that's where they are. these aren't showstoppers, just the ordinary and banal "oh, that doesn't work, this fixes that, wonder if there are side-effects" with context diffs. many more and i'll just create a cvs tag and manage the private (to me) tag and HEAD cvs tags.
signature left on blank check, reward if found
Semantics play an important role here
In my experience both as a developer (on other platforms) and as newbie user (on this one) is that we lack common understanding of terms AND terms that accurately depict what is being reported.
For example, in Bugzilla, everything is a "bug", from inappropriate user choices, to code problems, to requests for new features, to snarky comments about a design choice.
My suggestion is that perhaps this community work on a better issue tracker, that perhaps start with a taxonomy that more accurately reflects what a user experiences when they run into a problem.
I would submit there are some basic problems all users face:
1) Understanding the context of the problem they are facing. Is a Drupal problem? Is it an OS problem? Is it a MySQL problem?
2) If they understand the context of the problem, do they understand the logical structure of the context they are currently in? I.e. if you don't understand how modules work and are configured, or how templates work, why the hell won't your lists sort properly (whatever that is).
3) You may understand the context and logical framework, but you don't understand an anomoly in code behavior. Is it there for a reason? Or is it a "bug"?
4) You may have actually located a bug (an unintended result). Ok...now we're at the level of bug. But it needs to be replicated, the source of the problem located, and potential solutions identified. In many cases, there are multiple ways to solve the problem, so the developer should mediate between best choices, hopefully in a transparent manner.
5) You may have located a difference of opinion about a design feature or workflow process, a "new feature," not a bug. In that case, the user needs to be fed into a development cycle, not a "find the problem, propose solution, code solution" cycle.
I think a lot of the frustration on both sides of this exchange has to do with an inelegant solution to a complex set of observation and decision trees.
There's a concept used in the military call the "OODA Loop" which refers to a cycle of decision-making: Orient, Observe, Decide, Act. (Its a decision-cycle used to explain the qualities that make a good fighter pilot who has to survive in a highly dynamic and dangerous environment).
I would submit that we (the developer community at large) haven't really come to grips with a good framework to translate newbie user experience into actionable tasks. Perhaps this is something we could work together on.
I've done some of this...
...changing things to support requests, etc. The two biggest reasons for this are either because:
a) the bug report is flat-out incorrect and not a bug (i.e. someone missed a setting somewhere).
b) there is not enough information for me to reproduce the problem, or even to take a stab at what the problem might be.
I firmly believe the onus is on the bug reporter to include enough information for developers to have a decent shot at determining where the bug might be found. I usually do not even file a bug report until:
1. I have tried basic troubleshooting steps, like disabling all contrib modules.
2. I am able to itemize the specific steps I took to achieve whatever error/behaviour (click on this, then do that, then blah).
3. I have tested it under at least two different Drupal versions (4.7 and HEAD, for example) and/or environments (here I have a local XAMPP setup as well as my hosting server which is on Linux and an older version of PHP) and am able to report if I see the same symptoms under both.
#3 might not be an option for everyone, but #1 and #2 most certainly are. If your bug reports show that you've done some homework into the issue, this indicates that you have spent some time looking it and the problem is probably not just something silly you've accidentally overlooked (this happens to everyone from time to time), and also makes it much more likely that someone will either be able to duplicate it and find a fix, or at least have an idea where to start looking.
For illustration purposes...
Here's a really good example of dos and don'ts in a bug report:
OG ROLES module error on page "configure member roles"
First post essentially says: "I'm getting this error and I don't know why."
#1: Developer responds with, "Can't duplicate, need more info. Can you try...."
#5: Developer marks bug as fixed since poster seems to indicate bug is no longer present.
#7: Bug submitter re-opens bug, this time detailing exactly what they did and where they went to experience the error.
#8: Developer fixes bug in 5 seconds. :P
If more people would submit bug reports like #7, a lot more problems would get fixed around here. ;)
Proposed New Status Issue?
Perhaps when a bug cannot be confirmed to exist (active) but the issue is premature to be closed, there should be a new status for the issue...unconfirmed. Without such a status, developers are forced to either keep the issue as active or close the ticket. A close status does assume (to many) that either the issue has been resolved or confirmed not to be a bug.
Mozilla does this. In fact I had noted a bug in the default configuration for LDAP in a Thunderbird 1.5 nightly that didn't get resolved until four months later. It was not until 1.5 was released and other users could confirm that the default configuration for LDAP caused serious problems that the issue was placed from unconfirmed back into active mode. If the ticket had been closed, users may have assumed the issue was fixed or that I had been off my rocker in the solution I and others offered (and implemented in a later release).
Bryan
My Drupal Site:
CMSReport
+1
This is a very good idea that would substantially reduce the frustration on both sides.
I think an unconfirmed
I think an unconfirmed status would also reduce the amount of duplicate bug reports. I think people see closed and not knowing that they can open up the report again create a new one.
Taxonomy + better bug submission form?
In my own experience, one status is 'submitted,' and another 'confirmed.' Submitter and confirmer both need to agree a bug is fixed before the bug is closed (unless, for some reason, one or both become unavailable.)
Submitter produces a recipe, if possible, for reproducing a bug. If there is no recipe, it's a problem to fix, but the nature of some bugs is that they are intermittent.
A developer -- hopefully a developer of the code in question -- can intervene with an 'as designed' status. If you disagree, provide feedback to the project, or go build one the way you like it. (;^)
At any point in a bug's lifetime, if someone has pertinent details that more precisely describe the conditions under which a bug occurs, that description is welcome. This is especially valuable with intermittent bugs.
Particularly in open source, there is lots of regression, because different people make the same mistakes when they aren't in communication. So you have to be able to re-open bugs, even if they are a year or two old.
It would be extremely useful to have, not just a taxonomy, but a better bug submission form that walks submitters through best practices, and that provides organization of the info for people reading the bug.
I agree with Webchick: If a bug has 'submitted,' 'confirmed,' and 'has recipe' all checked, it likely will get killed in a hurry.
D Icenogle
Seems like a whole lot of
Seems like a whole lot of ifs to replace a simple "unconfirmed" message.
I think an "unconfirmed"
I think an "unconfirmed" status is the best way to go to categorise those issues that exist somewhere between an active and closed bug.
----------------
Dominic Ryan
www.it-hq.org
What?
The point of this string is not to replace messages, it is to improve bug handling. The proposal is to clearly mark the status of a bug and supporting documentation, which will both improve the quality of bug submissions and expedite fixes.
Confirmed/unconfirmed doesn't matter. It's semantics. In practice, though, it makes sense that someone submits a bug, giving the bug a status of submitted, but not confirmed. Someone other than the submitter replicates the bug and marks it "confirmed."
The developer submits a patch -- a proposed solution -- and marks the bug "resolved."
Submitter and/or confirmer test the solution (how this works is a policy decision) and if it works marks it "closed."
These are common terms for bug handling in the software industry.
D Icenogle
What status does the project
What status does the project manager give the submitted bug if they can not replicate it? setting it to unconfirmed is a much simpler method of saying more information is needed. All the noise about recipes and such is just a longer road to take to get to the same point.
Semantics are important when they are accepted (status quo) standards. Unconfirmed is used by all bug tracking software.
You're missing the point.
You're missing the point. The bug has a status of "submitted" until it is replicated (which is to say "confirmed." It's like no one has to vote until a motion is seconded. A project owner may not even worry too much about it until it is marked "confirmed," which is to say someone replicates it. What's unclear about this?
Providing a recipe to reproduce a bug IS A LOT MORE THAN NOISE! It's the best way to go to get a bug fixed. It is the best practice.
Use "unconfirmed," if you must (though you're dead wrong about all bug tracking software using that term.) Semantics are just semantics. Don't dwell on it. Focus on the process. Do you really think it's a bad idea to ask people to provide a recipe for reproducing a bug?
But leaving it at submitted
But leaving it at submitted does not tell the person who found the original bug anything about what is happening inbetween time. This is why unconfirmed is so useful. Perhaps the developer does not have access to the same environment. In this case even a recipe would not help. Setting something to unconfirmed will prompt someone to test it again. Also it is much more friendly to have and middle ground and not just black and white decisions on the status of a bug. It is a response that lets a user known that the developer is aware of the situation but needs more time or other help. What you are saying is things should be "open" then "closed" and never put on "hold".