When submitting a bug report, the preferred template is as follows: Brief description Steps to reproduce Expected results Actual results Description: Be brief. Do not insert your own theory as to why something doesn't work. This throws the developer off. Example: I do X, expect Y, but instead I get Z, therefore "x doesn't accept booleans". In the developer's mind, because the very specific problem is booleans, he looks there first, sees there's nothing wrong, ignores the rest. If you keep doing this it turns into "boy who cries wolf" syndrome, and people stop listening... Steps to reproduce look like this: Launch Renoise Open the demo song "Vivace - Jong Belegen" Press spacebar Click the Pattern Matrix Button ... The more precise the better, the less precise the shittier. Expected results: You expect something to happen. Describe it here. Actual results: Instead, something else happens, and this is wrong. Describe it here. Final considerations: Don't post a bug report as a reply to some thread. Instead, start a new thread. This ensures someone actually looks at your issue. Also don't start a new thread on a bug already reported in another thread, this will just make the programmer ignore you for ever. Screenshots make the bug report 1000 times better. A video capture makes the bug report 100000 times better... but if you're reporting bugs in command line applications just copy and paste, this way the content can be indexed by search engines and usable for other users and programmers. When you pay for a coffee, you're not paying for a future cup of coffee, those are bonus, they are not the product at the time of purchase. The same applies to the software industry. Reasonable cost of fixing the average bug in software industry: A day of work (8 hours) * 50€ = 400€ ==> this is below minimum wage and provably living in a squat or worse... Enthusiasm for fixing poorly explained bugs with flamewar undertones at the same time as developing awesome new community driven features for next to nothing: 0. Different kinds of bugs: Heisenbug - A bug that disappears or alters its characteristics when an attempt is made to study it. by [jacob] Higgs-Bugson - A hypothetical bug predicted to exist based on a small number of possibly related event log entries and vague anecdotal reports from users, but it is difficult (if not impossible) to reproduce on a dev machine because you don't really know if it's there, and if it is there what is causing it. To find these you will need to invest in a Large Hadron debugger. by [runrunraygun] Load-bearing printf bug - When a line of debug output is required for the code to work - the code does not function if you remove it. by [Ken] Different kinds of bug reports: Smug Report - A bug submitted by a user who thinks he knows a lot more about the system's design than he really does. Filled with irrelevant technical details and one or more suggestions (always wrong) about what he thinks is causing the problem and how we should fix it. by [aaronaught] Drug Report - A report so utterly incomprehensible that whoever submitted it must have been smoking crack. The lesser version is a chug report, where the submitter is thought to have had one too many. by [aaronaught] Shrug Report - A bug report with no error message or repro steps and only a vague description of the problem. Usually contains the phrase "doesn't work." by [aaronaught] Fermat's Last Post - A post to a bug tracker/email list/forum in which the author claims to have found a simple fix or workaround for a bug, but never says what it is and never shows up again to explain it (even after others have been puzzling over the bug for years). by [alan moore] Floater - The case in a bug tracking system where a bug report remains "floating" at the top of the queue, but never gets assigned to a developer, maybe because there is a workaround in place.
Very helpful for people that go....why doesn't it work! I am doing a floater right now. But it is in a different context Thanks for the share, definitely bookmarking this one.
