I have noticed a lot of questions on this site getting closed as a bug report when I do not think they should be getting closed. With our current system, a question could legitimately be considered a bug report if the question is something like "Blender crashes when I do this" That is merely a user stating that blender crashes when something is done. And in that case all the question is is a report of the bug and should be closed. However, If the question is something like "Why does blender crash when I do this?" It is a question asking Why it happens. In this case It would be appropriate to answer the question saying something such as,

"This is a known bug. Possible workarounds include __________ Or you could try this _________ instead. the developers might be fixing this in the near future"

In this case it is Not a bug report. It is a legitimate question of a user wanting to know Why something is happening. and Not a direct bug report. and should Not be closed.

So my question is this- Is the bug report close reason overused on this site, and what should be done to fix this problem if it is?

  • 1
    $\begingroup$ I feel that most closed questions are closed to quickly. For the case where someone shows up and asks how to find Maya's 'Make Dinosaur' button, obviously that should be closed. However, if someone asks about a work-flow that involves 3rd party software, nobody should even be voting to close that until a week has passed and the issue has been thoroughly discussed. It should be absolutely clear that the person's problem is only solvable on the other end of things before deciding that it's not a Blender problem. $\endgroup$ Mar 15, 2015 at 6:17
  • $\begingroup$ Also see When should a question be close as a bug report? $\endgroup$
    – David
    May 31, 2015 at 18:32

2 Answers 2


There are some situations where it could be more constructive to leave the question open so it can be discussed even if it is bug related.

Several areas of Blender have multiple pathways and if one tool fails because of a bug, it is not necessarily the case that all available work-flow options will fail.

If a question like this is closed for being a report, alternate methods do not have a chance to be brought up by other people who have found a work-around that can accomplish the same task but in a different way.

Automatically sending people to the tracker without discussion can also lead to the tracker becoming filled with nuisance reports and this can lead to issues for developers who have enough work to do already without having to sort through issues that could have easily been dealt with here.

If a question is closed for this reason and there is no discussion on the topic; every time someone comes here with a similar issue, they will think that it has not already been discussed because the other similar questions are not available. Now the nuisance question is right back again and now it has to be closed.

Leaving them open or directing the user to a page where the problems have been linked together can help to prevent these types of questions from repeatedly being asked.

Enough bug reports have been moved onto a to-do list instead of being fixed right away and when this happens, alternative solutions have to be used.

Not every code problem is going to have an immediate solution, some may never have one.

In cases like this, artists discussing work-flow alternatives needed to work around these bugs is really the only available option.

The following example shows a bug report that is valid; However, if it had been brought up here(and left open), then it could have been a discussion on how to avoid the bug in the first place.


Coders and algorithm designers cannot bear the full weight for everything that can go wrong with a complex system of tools.

Artists should have multiple ways around software weaknesses so they are not tripped up when bugs are encountered.

It helps to know how to avoid encountering those situations to begin.

One way to learn these things can be to make bug-report related questions into discussions instead of closing them.

Now bug-reports can be focused on problems which cannot be solved by work-flow solutions.

There should be no hurry to shut them down and move on as quickly as possible. That goes for many of the other 'close' reasons unless they are spam or abusive.

A particular bug report discussion here can be good cross-reference for the actual bug report since artists showing up here may have something to contribute.

If an artist shows up here a few months after the question is posted and recognizes a pattern to the bug based on similar issues they've been having, it may now become solvable instead of sitting idle in the Tracker for several more months(or years).

If it's been discussed and decided upon that a serious bug is present, the person can be referred to the tracker and asked to post the tracker URL on the related page here on this site.

Now anyone who finds the page will also know where to find the bug report, but only if the page here is still open.
This brings more opportunity for the problem to be solved because there will be more people involved.

If a developer reports, on bug tracker, that the issue has been solved, the page here can then be reported as being no longer valid. Now it can be removed.


I would guess most of the questions closed as bug reports are correctly being closed.

Some rules of thumb which give a good hint that the question is in fact a bug report.

  • You have to look at the source code to answer it. (example, you must be a developer).
  • The software is not working as it should and this would be better brought to developers attention.
  • If the error is something which used to work in older releases.
  • If the error is hardware related (graphics issues, OpenGL).

There are valid questions...

  • General questions such as why Blender fails on some hardware (graphics-cards, touchpads... but not specific models)
  • General Questions relating to a class of errors (out of memory, invalid files, unsupported OpenGL versions... for eg.)
  • Questions about known limitations *

* What is/isn't a known limitation isn't clear, for users, we do document these, however sometimes we could do better too.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .