"Not a bug" discussions

[OdinYggd]

DID YOU KNOW originally bugs were literally bugs. Computers were programmed with physical transistors and sometimes insects would get in and short-circuit something, causing a bug. (Not sure if this is actually correct, from one of my cooler teachers at some point and it stands to reason).

Not quite. In the early days of electronics, computers were room-sized appliances containing panel upon panel of relays. These relays would sometimes get stuck for one reason or another, leading to malfunctions. A particular incident where a relay jammed and was found to have done so because an insect had become stuck in its workings is how the term bug came to be attached to computer malfunctions. I've actually experienced the same phenomena at work, on a 1960s vintage machine that I maintain. A relay jammed one day, and sure enough there was a dead insect stuck between the relay contacts.

The definition of a bug is a tricky one. It's not something "unexpected" or "unintended" because that can be good, bad, neither, or either depending on your standpoint. A reasonable description might be "a function written in a way that results in behaviour contrary to requirement". Usually this would result in crash, such as returning/expecting the wrong type, or forgetting to dispose of an object causing a memory leak, or out-by-one error (year 2000 celebration is good example, the new millennium actually started in 2001).

In the case of Y2K, there were actually two bugs. The first was that some architectures had used 9999 as the signal to indicate end of program, making these programs crash on 1999-09-09 because of the common use of 9/9/99 notation. The second bug was that programs using the mm/dd/yy notation would roll over to 1900 when given a year after 1999. A piece of banking software I used at the time experienced this bug firsthand, Kiplingers CA Simply Money would treat a date with 00 as the year as being 1900 and report all kinds of errors about the offending transaction.

Modern usage, bugs usually appear as unintended or unexplained behaviors. There is also the painfully obvious bugs like memory leaks and zombie processes.

Under this logic, a bug might be inserters moving items in the wrong direction or the wrong quantity of items, or trains saying they're at the wrong station, or refineries requiring petroleum to craft, and basically any non-hardware-related crash. If it's "A single Fast Inserter doesn't keep up with a T3 Assembler making Copper Wire with speed mods" then that's not a bug. Inserters aren't required to do that.

Something else commonly misused is "Glitch" - Some users call any problem a glitch, usually when something doesn't save properly or they get something they didn't expect. I would use this to describe a hardware malfunction due to wear, damage or misuse.

One of the biggest difficulties in debugging something like Factorio is user hubris. The user puts it together in a way that they think is right, but actually missed an important detail. They then are so certain that they have it right but it doesn't work that the apparently critical detail gets overlooked repeatedly, and the problem appears in a bug report that other people are not able to reproduce- because they didn't miss that detail.

So whoever answers the ticket then has the difficulty of convincing a user who is sure that they have it right that they've missed something important and it is not a bug because it is in fact put together wrong. I admit I've done this myself more than a few times, it is way too easy to blame the machine when the problem is actually the user.

[Lee_newsum]

here's an example, contrived as it may be:
Factorio 13.0 come out. My inserters are picking up two items instead of one that breaks my factory.
I raise a bug report describing that all inserters are getting the stack size bonus and not just the stack inserters.

I put a bug report in on this as I halt the inserters would work the old way and the stack inserters would work the new way. at lest that is how I read it.
and I got "not a bug" but a fix to how the inserters worked was added.

[Sephrat]

First of all, replying to suggestions made on this topic: I think adding more categories (subforums) to the bug section won't give any more clarity but will only look like a way for the devs to "protect" themselves. That's playing with words, it will only build a fence between the users and the developers.

Now, back to why I came here in the first place. After reading this and that*, and many other devs' replies to bug reports, I decided to share my thought on this topic, being myself a developer on a completely different field (ERP maintenance). I'm pretty sure the following example applies to many other fields, sorry if that's basic stuff to you.
In my business we have basically 3 steps leading to a development:

1. the final user wants the software to behave this way.
2. A functional/business consultant listens to them and writes down how the software is supposed to evolve to fit the user's need.
3. A developer reads the specification and makes the required changes to the software

Whenever a bug report is made to the developer, their every day "fight" is to prove that the software behaves exactly as specified, no matter how silly it behaves. Why? Because they want to prove it's not their fault, but the consultant's. So that when we make statistics out of those bug reports, they can say "only 20% were caused by us, the rest are feature requests".
This is how we manage to be profitable because the client (in 95% of my case the consultant is my client) has to pay for a feature request (again, no matter how obvious it is), whereas if it is an actual bug (there is a difference between what was specified and what was actually developed) it is covered by the warranty and we have to fix it "for free".

However the final user doesn't care if it's the consultant or the developer that did its job wrong (is it a deviation to the specification: a "feature request"?). They don't even care if they asked it wrong in the first place: now that they've formulated their request differently, they just want the software to behave properly. Because that's the way to go: the first choice that was made was wrong.
Why did this bug or defect (terminology only matters for the developer) appear in the first place? The trouble is that as involved as we developers can be, we don't always have in mind every consequence a technical choice can have on the user experience.

Back to Factorio development livecycle, I think the line is not so clear between the consultant and the developer. AFAIK, developers are more involved in the creativity (specification) part. I guess that's where the difference lies between some developers' reply: some are more focused on the technical part (they will fix bugs with the speed of light), whereas some are better at support and understanding the user's point of view. That's just the way people are.
Bottom line: I believe some borderline bug reports shouldn't be classified this quickly as "not a bug", even if the same report has been made multiple times. In such cases, it can be a sign that what you thought was originally a good idea may not be the best solution after all: maybe it's time to think it through twice. To be more specific, I think most of the edge-cases of bugs classification are in the GUI part (from what I read in the bugs section, see links above).

Also, the user always wants to be right. Think of all the companies you call when you are pissed at them, and they always have pre-written replies that all basically say the same stuff "I feel your brain bro, but there's nothing we can do about it", only all wrapped up so that you don't feel angry at them after hanging up. I think that's what is missing here. I'm not saying that's easy: it's hard to tell the difference between a sincere apology and a nasty ironic reply when it's all written down. When you don't want to spend time on it, if you are in doubt (bug or defect?), just make the user happy. There's no difference for the devs to put the topic in "Not a bug" or "Won't fix". Just say "thanks" and put it in "Won't fix": you will make the reporter happy and the debate will be closed. It won't change the fact that you'll get the same bug report two weeks later. But hey, that's what we call "Support"



TLDR: when classifying if a bug is actually a bug, the devs need to think "out of the box". Feature requests are for new needs only, not for tweaking one that is already developed. If you don't want to tweak it, just say "Won't fix" and every one will be happy.


Note: I hope I don't sound too aggressive to the devs, I'm not very comfortable with English at this time of the evening. I'm only trying to give my two cents so that we can have the best experience. Keep up the good work.

Right, should I put a potato at the end of this long post or...? ---> []

* Sorry Rseding they're the ones I found first, nothing personal here

[Deadly-Bagel]

In the case of Y2K, there were actually two bugs...

I was not referring to the computational bugs of Y2K but the fact that we celebrated the new millennium in the year 2000, when the new millennium actually started in 2001. "The biggest out-by-one error the world has ever seen and it was not caused by a software developer" lol.

One of the biggest difficulties in debugging something like Factorio is user hubris. The user puts it together in a way that they think is right, but actually missed an important detail. They then are so certain that they have it right but it doesn't work that the apparently critical detail gets overlooked repeatedly, and the problem appears in a bug report that other people are not able to reproduce- because they didn't miss that detail.

So whoever answers the ticket then has the difficulty of convincing a user who is sure that they have it right that they've missed something important and it is not a bug because it is in fact put together wrong. I admit I've done this myself more than a few times, it is way too easy to blame the machine when the problem is actually the user.

I don't think this applies to many bug reports... Yes you might get a lot of users thinking that something is a bug initially but then they either locate the problem or post in the Gameplay or Technical Help forums rather than Bug Reports. The problem is more that a player wants something to behave differently to suit some obscure or out-of-bounds setup they've got and log it as a bug.

TLDR: when classifying if a bug is actually a bug, the devs need to think "out of the box". Feature requests are for new needs only, not for tweaking one that is already developed. If you don't want to tweak it, just say "Won't fix" and every one will be happy.

I get where you're coming from but these are different worlds in many ways I think. Factorio is still pre-release so bugs are expected and need to be dealt with quickly, while features are a much lower priority and are better suited for major releases. So basically devs need to heavily monitor one and only check the other when they're gearing up for a new release (but still keep an eye on it).

I agree with your definition of "Feature Requests" however that term is not used here, we have "Ideas and Suggestions" and "Balancing" which covers all types of requests. If anything, the READ BEFORE POSTING topics need updating to include what the devs consider a bug to be so that the players can compare their problem to that definition and post it in the correct place. If they ignore that then tough.