Stories
Slash Boxes
Comments

SoylentNews is people

posted by Blackmoore on Friday December 19 2014, @06:47AM   Printer-friendly
from the how-many-techs-does-it-take-to-change-a-lightbulb? dept.

Linux Magazine carries another issue of Bruce Byfield's Blog in which Bruce takes on the futility of filing Bug Reports using the typical on-line bug reporting tools that are used by much of the free software world (as well as some proprietary software developers).

Byfield, an ardent open source supporter, makes the case that the current generation of bug reporting software is misguided at best, and explains why he would rather blog about a bug than file a bug report. He compiles a list of impediments that most of us have encountered while submitting a bug report to our favorite distro or package maintainers.

Even if I can spare the time to enter a bug, I have to be strongly motivated. Every bug-tracking system that I have ever seen is designed far more for the needs of developers than for those who want to report a bug.

Among the problems Byfield clicks off are:

  • You have to create an account, you may end up with a dozen of these
  • You have to know which component of the software is the problem
  • Even a combo box list of components may not be meaningful
  • Need to open the (often failing) application to find the exact version number
  • Need to assign a "Severity", too high - it gets dismissed, too low - it gets ignored
  • By the time you get to enter a description, you're already exasperated
  • Then you have to list any of your futile attempts to fix it
  • Often you need to attach a file - which usually means crafting a special example
  • Before you are done you've spent a minimum of 30 minutes or maybe an hour

[More after the break.]

Then your bug enters the "Bug Bureaucracy".

Much of the problem is that I am an amateur at bug-reporting, but I am dealing with those who regularly handle bugs. I am likely to be excluded from much of the discussion, or, even worse, addressed so condescendingly that I get the feeling that, if we were talking, the experts would be speaking slowly and exaggeratedly and making broad gestures with their hands to ensure that I would understand.

Byfield then laments the fact that the experts are more interested in closing the bug report than actually fixing anything. He sums up with the conclusion

The truth is, bug-tracking systems are a tool for insiders. For outsiders, they are a form of hostile bureaucracy that discourages their participation in endless numbers of ways.

Personally, I file quite a few bug reports, being careful never to file on obsolete packages, I've learned the hard way never to file when running a tainted kernel, I include examples, screen shots, I've complied with requests for core dumps, traces, even source files. My bugs have lingered in the queue, sometimes for YEARS, often till the march of time and new versions get them closed as obsolete, only to appear un-fixed in newer releases. In the end, the result is usually the same: Wait (months) for the next release.

Disclosure: I handle bug reports in my day job, and my employer's system is no better than anyone else's. I'm not allowed to run the train...

Soylentils: What is your impression of the current crop of bug reporting tools? Have you run into the issues Bruce describes? Is the process even remotely suitable for end-users?

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1) by aXis on Friday December 19 2014, @06:57AM

    by aXis (2908) on Friday December 19 2014, @06:57AM (#127411)

    The reason these forms are so involved is that far too many users are just dense. I've lost count of the number of times a user sent me a support request with the description "it broke".

    Given the chance, users wont tell you:
    * What actually broke
    * The actual name of the program "my internet broke", versus "chrome browser"
    * Any details of the error messsage
    * Anything that could be used to reproduce said bug so it can be replicated and investigate on a developers system.

    Now I agree there should to be a happy middle ground, but there needs to be some structure to it. Even a screenshot would be massively helpful in many canses but a lot users wont even do that.

    • (Score: 3, Interesting) by mojo chan on Friday December 19 2014, @08:28AM

      by mojo chan (266) on Friday December 19 2014, @08:28AM (#127425)

      This. The number of crap, useless bug reports is so overwhelming that programmers quickly try to raise the bar for reporting them. It also helps filter out cases where the user is just an idiot or their PC is broken. Any bugs that are genuine and affect a few people will still get reported.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      • (Score: 2) by dlb on Friday December 19 2014, @01:54PM

        by dlb (4790) on Friday December 19 2014, @01:54PM (#127465)

        far too many users are just dense

        cases where the user is just an idiot

        In a typical year I can interact with a physician, dentist, accountant, furnace repairman, auto mechanic, and maybe even a plumber or carpenter. Probably many other people who's common work day is quite atypical for me. But they don't seem to have contempt for my lack of common sense when it comes to understanding the intricacies of their trades. Instead they act as if they want to work with me (otherwise I would take my business elsewhere). And problems get solved. It's a good approach that's usually effective.

        • (Score: 0) by Anonymous Coward on Friday December 19 2014, @02:19PM

          by Anonymous Coward on Friday December 19 2014, @02:19PM (#127472)

          A very good point: Imagine the following conversation with your dentist:

          Patient: "My tooth hurts."
          Dentist: "Which one?"
          P: "Some back tooth on the upper left."
          D: "Which exactly?"
          P: "I can't tell more exactly."
          D: "So you expect me to repair your tooth and can't even tell me which one? Can you at least tell me the exact type of pain?"
          P: "The exact type of pain? What do you mean by that?"
          D: "Well, how does your pain manifest?"
          P: "Well, it hurts."
          D: "Yes, but which way does it hurt?"
          P: "Terribly."
          D: "So in short, you can tell me neither which tooth it is, nor the exact type of pain, yet you expect me to somehow fix it?"
          P: "It's your job, isn't it?"
          D: "Sure, my job is to fix teeth. But you're not describing your symptoms accurately. So please come back when you've learned to describe your symptoms accurately. Good bye."

          • (Score: 0) by Anonymous Coward on Friday December 19 2014, @02:45PM

            by Anonymous Coward on Friday December 19 2014, @02:45PM (#127483)

            I was thinking about this the other day, but in the context of HVAC.

            Customer: It's too hot.
            HVAC: Let's take a look. You don't seem to have an air conditioner. Would you like me to install one?
            Customer: Yes I do! Why are you so rude?! *points at open freezer* It's driving up my electrical bill and it doesn't even cool my house!
            HVAC: Leaving your freezer open will only add heat to your house. I have a special on air conditioners. Would you like me to install one for $500 today?
            Customer: $500?! What a rip-off! It keeps my food cold! Why won't it keep my house cold?!
            HVAC: In order to cool the house, we need to transfer heat out of the house to the outside.
            Customer: You're full of shit! Why are you being so technical?! You're mean!

            *Customer goes online*

            Customer: HVAC people always make everything too hard! Why can't it be easy?! They're always talking over my head! Meanie meanie meanie!!!eleven1! Why are there no women in HVAC?! They're all a bunch of sexist, bigoted, misogynists!

          • (Score: 1) by JaKe on Friday December 19 2014, @04:49PM

            by JaKe (2456) on Friday December 19 2014, @04:49PM (#127520)

            Ehm, not really. This is how this goes down:
            ...
            P: "Well, it hurts."
            D: "Oke then, lets have a look." Sticking prod in tooth. "Does this hurt?"
            P: "No."
            D: Sticking prod in other tooth. "Does this hurt??
            P: "AAAAAAYYYY??!!"
            D: "Hmm," Sticking prod in other tooth "and this?"
            P: "AAAAAAAAAYYYYYYYY!!!!!!!!!"
            D: "Oke," Sticking prod in other tooth. "this one too?"
            P: "YYYESSS!!!"
            D: "Oke, these all have to come out then. It's going to be costly replacing them, but as you've indicated, that's where the problem is."
            P: "Ehm, how much is it going to cost, approximately?"
            D: "Well, something like $x000.- each."
            P: "Oh? Maybe it's not so bad, can you do just that one, that one actually hurts."
            D: "Let's see." Looking closely at the tooth. "Oke, that's actually the only one that has a cavity. Why I just fill that?"
            P: "What would that cost?"
            D: "Oh, about $y00.-"
            P: "Much better. Thanks."

            See what happens here? There's almost zero cost in dropping a complaint, but a significant cost in researching and fixing the problem, unless a specific report is given.
            This imbalance puts all the cost with the developer and the near-zero cost at the (possibly large) user pool. See how easy it is for the developer(s) to become overwhelmed?
            So, to balance the scales the developer tries to offset some of his/her research cost to the one filing the report. It's all economics.

          • (Score: 2) by khedoros on Saturday December 20 2014, @09:06PM

            by khedoros (2921) on Saturday December 20 2014, @09:06PM (#127831)
            At some point, the dentist will say, "OK, since you can't tell me, let me prod a bit to test". The patient might say "OK, but no prod, you can only make a visual examination. Don't stick a mirror in my mouth, either." Situations similar to that are why our software logs the living hell out of everything possible, because you end up with customers that can't give you any information beyond "it doesn't work", and won't let a support tech or development engineer actually examine the problem (i.e. examining logs and configuration on the customer's system to diagnose the issue). That's perfectly understandable; no one wants someone outside of the company poking around on their system. Now, imagine that the dentist is looking at a mouth with a thousand teeth, any one of which might be located in a different place than usual, either by design, or because the customer decided that they liked that tooth better where they put it. They won't open their mouth, won't let you prod at their cheeks, and won't allow an oral X-ray. That is what a software developer is dealing with, a lot of the time. In general, people offer doctors and dentists a lot more leeway to conduct the tests that they think are necessary. Accountants, plumbers, physicians, mechanics, etc get access to what they're fixing in ways that software developers can only dream about.
        • (Score: 1, Insightful) by Anonymous Coward on Friday December 19 2014, @02:46PM

          by Anonymous Coward on Friday December 19 2014, @02:46PM (#127485)

          > otherwise I would take my business elsewhere

          That is the key. If you aren't paying for a support contract then your bug reports aren't money earners. They are in fact a trade for service - you want the bug fixed but all you have to offer the developers is your help in improving their project. So you should expect to put in an effort commensurate with the value to you of getting the bug fixed.

          On the other hand, if you are paying for support then you have every right to expect hand holding through the process of bug reporting and getting it fixed.

          • (Score: 2) by HiThere on Friday December 19 2014, @09:43PM

            by HiThere (866) Subscriber Badge on Friday December 19 2014, @09:43PM (#127599) Journal

            Are support contracts worth anything these days? 20 years ago hardware support contracts were well worthwhile, but software support contracts were a waste of money. (This was at my employers shop, so we're talking proprietary software here.) I usually did better working around the problem myself than trying to get the support service to fix anything. It was usually quicker (took me less of my time) too.

            I haven't heard anyone saying that support contracts had gotten any better, but then people don't usually post that kind of thing, so it wouldn't surprise me if it were true.

            --
            Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
            • (Score: 1, Insightful) by Anonymous Coward on Saturday December 20 2014, @03:25AM

              by Anonymous Coward on Saturday December 20 2014, @03:25AM (#127647)

              Support contracts are not commodities. There is no relationship between the support for one product and the support for another. Each must be judged on its own merits.

            • (Score: 3, Interesting) by khedoros on Saturday December 20 2014, @08:50PM

              by khedoros (2921) on Saturday December 20 2014, @08:50PM (#127826)
              I'm a software engineer for a company with a set of hardware+software products in the 6-7 digit (USD) price range, and they're always bundled with a support contract. Requests filter up through a few levels of support, and problems are usually solved either by providing a known work-around, some configuration advice, etc. Every so often (under 1% of the time), there's a bug without a work-around, or a customer that isn't satisfied with the work or inconvenience required to implement it, and dev ends up providing a custom binary (and filing a bugs against unreleased versions of the software). Customer escalations like that take priority over any new development that we're doing. So, I don't know about support as a whole, but I know that I try to do my part when an issue comes up for a customer.
        • (Score: 2) by Bot on Friday December 19 2014, @04:58PM

          by Bot (3902) on Friday December 19 2014, @04:58PM (#127523) Journal

          A valid point, but another is that a one on one interaction is different from internet reporting.

          Example. Guy writes free software Program which threatens the commercial interests of Corporation.
          Corporation submits bug reports which are fake, opaque, misleading.
          Now Guy has to make sense of it all while Corporation can point at the bug reports and say Client do not use this, it's buggy.

          Ideally bug reporting would consist of downloading a VM or container with the latest version, snapshotting before and after the occurrence and sending the diffs plus the action which triggered the bug.
          It would weed out race conditions, but also misconfigurations and highlight hardware/packaging issues.

          --
          Account abandoned.
          • (Score: 0) by Anonymous Coward on Friday December 19 2014, @06:20PM

            by Anonymous Coward on Friday December 19 2014, @06:20PM (#127538)

            I find the "try the latest release" I high bar to meet actually. It generally takes me months to trouble-shoot problems. On an active project, the lastest release may go through many iterations in that time.

            I also seem to have a habit of doing things just weirdly enough to break things. Often, my bug reports are stalled by finding secondary bugs for possibly unrelated packages. (Related: also checking that the problem is not between the keyboard and chair (which means finding the documentation)).

            Most recently, I was looking at filing a bug report over evince's new thumbnail feature (That I have not figure out how to turn off). When I search for existing bugs, there are numerous reports saying almost, but not exactly what I want to say. I half-expect the resolution to be "WON'T FIX" (It appears to be part of gnome) and that I should start using xpdf instead.

            BTW: in the tumbnail case, diffs won't help: it is a performance issue.

        • (Score: 0) by Anonymous Coward on Friday December 19 2014, @07:34PM

          by Anonymous Coward on Friday December 19 2014, @07:34PM (#127558)
          Try paying $$$ just like you pay your dentist etc.

          I treat bug reports fine, coz I'm paid to handle them. And if you pay $$$$$$/year like some of our customers, I sometimes even help fix problems that aren't related to the stuff they're paying us to support (yeah maybe a bit risky if I screw up, but just don't screw up ;) ).
      • (Score: 2) by jmorris on Friday December 19 2014, @08:53PM

        by jmorris (4844) on Friday December 19 2014, @08:53PM (#127587)

        The number of crap, useless bug reports is so overwhelming that programmers quickly try to raise the bar for reporting them.

        I'd say they just don't care and make it hard to report bugs to cut down the numbers. Have reported bugs before, never actually seen one closed though.

        For example, lets pick on RedHat/Fedora and have a look at this one that I submitted a year and a half ago.

        BZ976594 [redhat.com]

        Fully described problem, solution included. Reported against Fedora 18, still open three releases later. Still in status 'NEW' even, although I did update it twice as F19 and F20 were released to note the problem still exists, and even recurs during the upgrade process if you have manually fixed it previously.

        This isn't the exception, it is the rule of bug reporting via bug trackers. Not just picking on RH. Developers are eager to rip a mostly working subsystem apart and rewrite it but Open Source sucks at maintaining and bug squashing.

    • (Score: 2) by HiThere on Friday December 19 2014, @09:56PM

      by HiThere (866) Subscriber Badge on Friday December 19 2014, @09:56PM (#127602) Journal

      Actually, they are often impossible to fill out reasonably. I'll be doing something, and some process in the background crashes. I don't even know which process it was.

      Nearly as often I'll try to report on something where the system detected the problem and asked me to submit a bug report. But when I try it always tells me that the dump that was generated doesn't contain enough useful information to help.

      So, yes, they aren't worthwhile bothering with. I think it's been years since I've had one that was accepted. Just because I know what I was doing doesn't mean I know what was happening in the background.

      OTOH, I don't do assembly programming on Linux. I rarely even use gdb. What this means is that the tools are not designed to be used by the end users. If the bug reporting tool can't dredge enough information out of the logs, it's quite certain that I can't. I can usually figure out why my own programs crash, but I generally debug them with a liberal use of print statements. And I'm much more technical than the typical end user.

      Then again, it was discouraging to get bug reports responded to with "won't fix" or "works for me", though I do understand why some of these responses occur. It does, however, discourage putting effort into bug reports.

      --
      Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
  • (Score: 1) by d(++)b on Friday December 19 2014, @07:06AM

    by d(++)b (2755) on Friday December 19 2014, @07:06AM (#127412)

    Byfield, [... ] explains why he would rather blog about a bug then file a bug report.

    So the revolutionary idea revolves around first posting an article in his web-log and then filing a bug report.

    Is that it?

    No?

    Oh so... what yer sayin' is young nerds who should know the difference between IF/THEN and MORE>THAN habitually type the wrong damn thing into the undertoobs and we (the reader) suffer.

    Stop.it.dammit. It's a very "codey/mathy" distinction. Should be easy for us.

    • (Score: 3, Funny) by martyb on Friday December 19 2014, @10:38AM

      by martyb (76) Subscriber Badge on Friday December 19 2014, @10:38AM (#127436) Journal

      Urk! That mistake drives me *crazy*! I have no idea how it got through. Now fixed!

      Now, for completeness' sake, would you please submit a bug report [github.com] on it?

      =)

      --
      Wit is intellect, dancing.
  • (Score: 0) by Anonymous Coward on Friday December 19 2014, @07:15AM

    by Anonymous Coward on Friday December 19 2014, @07:15AM (#127416)

    ...well, the original headline.
    I didn't click the link and I didn't see the byline to notice who wrote it.

    he would rather blog about a bug [than] file a bug report

    "The squeaky wheel gets the grease."

    Most people who use the word "hopefully" use it inappropriately.
    This situation reminds me of the example I like to give of how to use it correctly:
    "She waited by the phone hopefully."
    (It's a very passive word.)

    -- gewg_

    • (Score: 0) by Anonymous Coward on Friday December 19 2014, @09:50AM

      by Anonymous Coward on Friday December 19 2014, @09:50AM (#127431)

      If most people use a word in a certain way then that way is correct by definition.

      • (Score: 1, Interesting) by Anonymous Coward on Friday December 19 2014, @11:38AM

        by Anonymous Coward on Friday December 19 2014, @11:38AM (#127443)

        You mean, by the conventional meaning of "correct". By definition would mean there's a normative definition of "correct", which would directly contradict your explanation of what makes the usage of a word correct (and which of course has to apply to the word "correct" as well). Well, at least I'm not aware that "by definition" would be used by the majority of people to mean anything else than "it is defined that way".

        • (Score: 0) by Anonymous Coward on Friday December 19 2014, @02:30PM

          by Anonymous Coward on Friday December 19 2014, @02:30PM (#127478)

          Words change meaning *all* the time.

          http://www.merriam-webster.com/dictionary/hacker [merriam-webster.com]

          This word has no less than 4 different meanings.

          They also missed at least 2 different definitions on this word. http://www.merriam-webster.com/dictionary/hack [merriam-webster.com]

          "by definition" unfortunately is not very good but usually 'good enough'. Many times usage is well ahead of the guys writing it down in the dictionary. Then some groups latch onto particular words for identity and do not like it when it changes.

          Or to put it this way 'aint aint a word because its not in the dictionary' as I was told as a child. Except when it is... http://www.merriam-webster.com/dictionary/aint [merriam-webster.com]

          The self proclaimed masters of our language are not. They are usually several years behind and actually miss meanings all the time.

          There are many 'new' words that really stick in my craw but I suck it up. However, for some people it really messes with them. Their internal dictionary is very ridged and unflexible.

          In the business world it is why you go over everything and get everyone to describe what they meant. As what they write down is not necessarily in your dictionary. I for one have a very hard time not using American colloquialisms when dealing with people from other nations. It only serves to confuse them and make communication harder. But I continue to try... However, they just burble out. You also need to do this because you can be dealing with sometimes 4 generations of people each with their own idea of what 'english' is.

          It is also very noticeable when watching older movies, books, or plays. You have to pay attention and sometimes go back and rewatch/reread it. Because there could be a funny play on words going on (usually a pun). Which made sense in 1940. However, in 2014 make little sense. For example many loony tunes have a rapid fire of movie jokes with puns that many times make no sense to me because I did not grow up in that era. I sometimes get the joke after I have seen whatever movie/book they are cracking on. Even pronunciation can play into how words change. I fully expect in my lifetime the word 'axe' to mean 'ask' and 'chew' to mean 'you'. That is just a simple matter of people writing as they speak.

  • (Score: 2) by bradley13 on Friday December 19 2014, @07:47AM

    by bradley13 (3053) on Friday December 19 2014, @07:47AM (#127423) Homepage Journal

    I've developed applications for end users (still do, though now more of a hobby). I've also filed plenty of bug reports, sometimes for OSS software via these online tools. There is one, great, central problem: reproducibility.

    For the end user - even for me, as a technical end user - it is not always clear what causes a problem. To take a real example, there is a horrible bug in OpenOffice/LibreOffice Impress. You are working on a presentation, and suddenly some random number of your illustrations are gone. Just...gone. I can use Impress for weeks without this happening, and then it will strike several times in the same day. I have never found a reliable way to provoke this bug - it happens seemingly at random.

    On the side of the developer, if you don't have that reproducible example, what are you supposed to do? Some random user claiming something doesn't work just isn't helpful. Lots of users are clueless, many (most?) problems are best resolved via RRU (Remove-and-Replace-User). If the user cannot tell you how to reproduce a problem, it is entirely understandable when the developers assume user error and ignore the bug report.

    --
    Everyone is somebody else's weirdo.
    • (Score: 0) by Anonymous Coward on Friday December 19 2014, @06:39PM

      by Anonymous Coward on Friday December 19 2014, @06:39PM (#127542)

      "sometimes for OSS software"

      Sometimes for OSS software you say? Tell me, have you ever gone to an ATM machine and entered your PIN number so that you could go buy an SSD drive?

  • (Score: 2, Insightful) by lentilla on Friday December 19 2014, @08:36AM

    by lentilla (1770) on Friday December 19 2014, @08:36AM (#127426)

    My experiences with reporting bugs closely match Mr Byfield's experience. Here are my examples:

    1. Fixed within a day - reported to an active mailing list
    2. Fixed in six weeks, but only after first sleuthing out a valid email address for the maintainer by asking other people because his was bouncing.
    3. Wording of a prompt should be improved. Patch attached. Bug unassigned and unactioned for 14 months.
    4. "Wishlist-style" suggestion effectively suggesting that the documentation might actually want to mention how to run the program. Outstanding for six months now. (Of course, having gone to the trouble of submitting the report - easily half-an-hour - I realised the package had been effectively superseded. Still, the bug remains, untouched.)

    On first encountering a bug, I first think "hang on, are you sure?" Once I've determined I'm not imagining it and can accurately and repeatedly duplicate it the next step is to ensure I have the absolute latest version. This may or not be a straight-forward process. I've found that whilst getting the latest source is relatively simple, getting it to run on my system (without screwing the system up) can be a significant hurdle.

    So after checking the bug still exists in the latest version, and has not already been reported in the tracking system, I can begin to file the report. I don't need to rehash the original article's commentary about now needing to create an account and jump through the hoops.

    I believe a system of triage is the best way to handle bugs. Kind of like the good old days where you'd simply email the developer and if they needed more information they'd ask targeted questions. The active development community should use a bug tracker, but most of the time I'd be happier if they created the entry in the tracking system themselves and then asked me to fill in the details.

    Bug tracking systems do indeed impose a massive barrier to entry. They are great for quantifying solved and outstanding bugs - but that presupposes the bugs even manage to be documented in the first place. Which I'm only likely to do if I'm feeling particularly generous. Given the barriers to entry and the my own experiences in getting bugs quashed - even when I've supplied the patch - I'm surprised we bother at all.

    Saddest of all is where I constantly read in the documentation "if you have a bug to report or a suggestion, please let us know". Wishful thinking at its best. I'm lucky - there's a good chance I can understand the problem (although rarely without a not-inconsiderable expenditure of effort, I might add). And if I can't supply a patch I'm likely to be able to point out exactly what needs to be done. I can only imagine what other people must find when they try to help improve software: incomprehensible questions and procedures followed by... deathly silence.

    • (Score: 0) by Anonymous Coward on Friday December 19 2014, @09:16AM

      by Anonymous Coward on Friday December 19 2014, @09:16AM (#127429)

      I agree about the importance of triage. There is nothing quite as disheartening as to see a years old bug with zero comments and status: new. As somebody has take the time to file, the least thing the dev could do is take a look. I'm sure most people would prefer getting a quick WONTFIX rather than seeing their baby languish apparently unnoticed for an eternity. On the other hand I realize that a lot of free software is developed as a hobby and thus lacks the manpower to react promptly and that the developer owns nothing to the end users, on the contrary. Still I believe many devs are quite interested in their users. I guess what might be useful is some automated statistics passed down to the dev. There should be a module or framework you could include with your program that'd send some data back, things like crashes and some usage patterns. Let the computer do the heavy lifting, that's why we bought them!

    • (Score: 2) by frojack on Friday December 19 2014, @07:36PM

      by frojack (1554) on Friday December 19 2014, @07:36PM (#127559) Journal

      Pretty much my experience as well.

      I've actually submitted a bug report that would take exactly one line of code to fix. (adding the name of account to the password request pop up on an application that can simultaneously be logging into any number of accounts.)

      Was told to use a password cache and enter them all at the start of the day, Several third party caches were suggested. Was told to use the same password for all accounts. Was told they needed a screen shot of the offending popup from their own application. Was told to enter the password for each account until it stopped asking.

      All to avoid having to make any changes in the code.

      --
      No, you are mistaken. I've always had this sig.
  • (Score: 2) by gringer on Friday December 19 2014, @10:29AM

    by gringer (962) on Friday December 19 2014, @10:29AM (#127434)

    For those who have not yet seen it, Simon Tatham has an excellent writeup of how to report bugs effectively, and why [most of] these frustrating bits should be included in bug reports:

    http://www.chiark.greenend.org.uk/~sgtatham/bugs.html [greenend.org.uk]

    --
    Ask me about Sequencing DNA in front of Linus Torvalds [youtube.com]
  • (Score: 5, Insightful) by Common Joe on Friday December 19 2014, @10:58AM

    by Common Joe (33) <{common.joe.0101} {at} {gmail.com}> on Friday December 19 2014, @10:58AM (#127439) Journal

    At the end of the linked article, he links to another of his posts and it addresses something called SpinachCon [linux-magazine.com]. From that article:

    User testing is often limited in free software. However, long-time advocate Deb Nicholson is developing a simple but effective way around the limitations: getting developers and users together and calling the result SpinachCon.

    My one time dealing with LibreOffice bug support was disappointing. I found a reproducible bug and described how I did it. Over the next week, the developer and I went back and forth. He closed it. I had it reopened. He wanted to ignore it and I tried to say "No, this is a real problem". It was a head scratcher for me and I finally just let it go. What was I going to do? Argue with him some more?

    I have been doing professional help desk work longer than I've done professional programming... and when I was programming, I did a lot of bug hunting. I understand the pain they go through. I wished I could have sat him down and showed him.

    I have the luck of usually having internal customers. If one of my customers finds a bug, I'll run over to their desk and watch the the program blow up in their face. SpinachCon seems to do something like that with external customers and I like that idea. Perhaps something like that could have helped me with the LibreOffice guy.

  • (Score: 1, Insightful) by Anonymous Coward on Friday December 19 2014, @11:46AM

    by Anonymous Coward on Friday December 19 2014, @11:46AM (#127445)

    "Need to assign a "Severity", too high - it gets dismissed, too low - it gets ignored"

    That's not a bug in the bug reporting system, but a problem in the handling of the bug reports. No amount of bug reporting system design can prevent bad handling of the reported bugs.

    I am likely to be excluded from much of the discussion, or, even worse, addressed so condescendingly that I get the feeling that, if we were talking, the experts would be speaking slowly and exaggeratedly and making broad gestures with their hands to ensure that I would understand.

    Again, that has nothing to do with the bug reporting system, but with the people who handle the bugs.

    After all, you also don't complain to the train manufacturer that the train staff was unfriendly.

    • (Score: 2) by cafebabe on Saturday December 27 2014, @05:22PM

      by cafebabe (894) on Saturday December 27 2014, @05:22PM (#129494) Journal

      don't complain to the train manufacturer that the train staff was unfriendly.

      That's a widely understood distinction. However, with software, people don't understand that different elements of a user interface are different programs written by different parties nor do they understand that services an/or data may come from different parties. Real examples:-

      1. Medical doctor described his patient CRM system as a "page".

      2. User with mis-understanding about filing systems, file associations and file requester globbing thought that files visible in a file requester were "owned" by an application and "borrowed" by a file browser.

      3. User receiving pornographic spam thought that messages were vetted and approved by email provider. User freely gave email to "vetted" parties which led to a vast escalation of pornographic spam.

      --
      1702845791×2
  • (Score: 0) by Anonymous Coward on Friday December 19 2014, @01:03PM

    by Anonymous Coward on Friday December 19 2014, @01:03PM (#127455)

    Software development and testing isn't for hipsters and brogrammers. It's for those who don't shy effort.

    • (Score: 0) by Anonymous Coward on Friday December 19 2014, @01:53PM

      by Anonymous Coward on Friday December 19 2014, @01:53PM (#127464)

      So you think mere users of a software should not report bugs when they encounter them?

      • (Score: 0) by Anonymous Coward on Friday December 19 2014, @02:26PM

        by Anonymous Coward on Friday December 19 2014, @02:26PM (#127475)

        The only thing you get out of them is "IT CRASHED WAAAAH" no matter what requirements you put onto bug reporting, removing the requirements just leads to developers also being lazy and not providing necessary steps, this is human nature with risk compensation and all.

  • (Score: 2) by richtopia on Friday December 19 2014, @04:29PM

    by richtopia (3160) on Friday December 19 2014, @04:29PM (#127517) Homepage Journal

    Most problems are difficult to describe without going through the above process. The only way I could imagine a causal bug reporting being effective is using a screen capture program so the user can recreate the bug on tape.

    This would need to be some dedicated one button solution (lowering barriers to entry and all). However I don't see it happening any time soon, aside from maybe proprietary software (expensive stuff, like scientific software with only dozens of customers using a specific feature paying thousands of dollars per seat).

  • (Score: 2) by nitehawk214 on Friday December 19 2014, @04:53PM

    by nitehawk214 (1304) on Friday December 19 2014, @04:53PM (#127521)

    The alternative to providing adequate information to track down and fix a bug is.... "Closed - Cannot Reproduce."

    There is a point to his rant though. For the closed-source projects that I have worked on for the past 15 years, no customer is allowed direct access to the internal ticketing system. Instead they send an email to a customer service rep, and that person has to send a dozen or so more emails to squeeze what the customer is really complaining about out of them, then the customer service rep puts in the ticket. In bigger companies a QA or BA person would actually verify that the bug is real (when possible) before it even gets assigned to a developer.

    The problem is that having people do these things for you costs money. Open source projects with no paid developers? Consider yourself lucky if there is a bug tracking system at all.

    --
    "Don't you ever miss the days when you used to be nostalgic?" -Loiosh
  • (Score: 2) by hendrikboom on Friday December 19 2014, @11:30PM

    by hendrikboom (1125) Subscriber Badge on Friday December 19 2014, @11:30PM (#127611) Homepage Journal

    It appears it hakes less time for a broken wrist to heal than for the person with a broken wrist to get the accessibility tools debugged.

    https://bugs.freedesktop.org/show_bug.cgi?id=74088 [freedesktop.org]

    Granted, that bug involves interaction between proprietary and nonproprietary software, which probably makes it all more difficult.

    -- hendrik

  • (Score: 2) by N3Roaster on Saturday December 20 2014, @01:48AM

    by N3Roaster (3860) <roaster@wilsonscoffee.com> on Saturday December 20 2014, @01:48AM (#127636) Homepage Journal

    Most times I encounter a bug, I'll track down the appropriate bug tracker/mailing list archive/whatever and determine that the bug has already been reported and move on. Finding the reported bug is useful as it gives me some perspective on if anybody doing the work thinks the issue needs to be fixed and perhaps the difficulty of fixing the issue.

    As a developer, I haven't set up anything special for tracking bugs. Anybody can open issues on github but everybody ignores that and just sends email or a phone call (the last one was from New Zealand, probably a hardware issue but I decided that my code should handle the failure better and got them something that recovers usably from intermittent hardware failure) or leaves a comment on some random YouTube video (I have no idea what prompts people to do that and unsurprisingly these are the worst quality bug reports) or sends a tumblr ask. A lot of times people aren't sure if they've found a bug or not. The real issues get sorted out, but it's not a process that scales well. I look at it as incentive to write fewer bugs.