Your thoughts about reporting bugs?

I was adding a FAQ-like question about bug reporting to our answers site when one of our trusted community members, Ashkan, replied to it as I was a part of the community and not a hired QA Specialist here at Unity Technologies.

His answer looked very much like some of the answers that I reply with to some of our users that are a bit unclear about their problems, so it made me think :idea:


- From the community's POV, what is the best way of reporting bugs?

- Can you help us at UT concentrating on fixable bugs by asking each other if you doubt whether your problem is a bug? (Of course you can - and you are good at it, but are you OK with that?)

- Do you have any wishes concerning the way we process bug reports?

- What kind, level, and exposure of information would help you better explain your problems with Unity?

 

First thing is to get rid of FogBugz, that thing is horrible, you can only reply in a back and forth fassion for a limited number of times before it stops showing any replies past a certain one, Unity is well aware of this fact and it has been a bug reported about the bug system now for over a year.

Aside from aformentioned format changes to the system, some real effort in communication as to the status of the report back to the users who reported the issue, some collaboritive system that takes that report, scans it for key words or common issue's and drops it into a system that is browseable by all users via a web interface. This becomes more of a system that other users can browse to see if the same issue was seen or experienced by others and counts up how many times it has been reported. Anyone assigned to the bug could add comments to it for others to read.

When we submit bugs, after the submission, have the system open a web page to the bug report repository with a lookup for any error code reported by the user, think Microsoft and how they allow you to do a "report problem" which in turn directs you to known solutions if any or documentation about the problem directly.

The problem is, no one actually knows if Unity is serious about the problem, sure the problem is reported, it goes into a black hole of hundreds of bugs, and thats about it. As mentioned in other threads I could link to, Unity might or might not ever get around to looking at or resolving the bug, depending on internal resources and in the majority of cases, Unity will not communicate back to the users about the bug unless further information is needed, so to the users, this simply looks like Unity has a huge file 13 cabinet where these disappear into.

Unity is growing exponentially, that said, so are the bug reports and frankly put, Fogbugz is not the place or the technology to use. It was fine when you had less than 50 subscribers to your product, it is not useful on an enterprise level with hundreds - nay - thousands of users, possibly tens of thousands of users.

So taking that into consideration, if a system is not put into place that catches each of these reports and combines the like problems into one, you will end up in utter chaos real quick. The internal support staff is great, but I would summize that 75% of the issues can be taken care of with a working bug report system that is fluid and interactive, something more than what Unity currently has, something that has a better hands off for people to look up not only their issues but common issues or the odd issues reported by other people.

The system could be 80% automated also, which means that when the bug is reported, the system takes over, catagorizes the bug, puts it in a bucket, and gives the user a link to watch any progress, if any, on the bug. People are happier when they know an open communication channel is available and can 'watch' progress on issues. Right now, it is a simple view, here is how it looks to the community:

"Unity has crashed send in bug report?"
..User says yes...
"Thank you user for submitting the bug"
..User can see the submitted bug on FogBugz...
..The report goes from open status to closed...
..User thinks.. was it fixed???...Sends in email or responds to bug asking what was fix...
"Sorry, we close things automatically after a while if you respond it gets re-opened, no ETA on resolution"
..User is more frustrated...

..Another 100 users come along and experience like problem, like issue, different situation, repeates steps above individually..very counter productive since all 100 users are unable to figure out if Unity is working on it, or if it is even a bug, but now Fogbugz has 101 users with a report that is similar in nature, and could have easily looked it up on a bug report site of Unity that shows a one line comment by Unity that says "No ETA on resolution", which then avoids the additional 100 comments on the same problem...

Right now, the system is very convoluted and very non-user friendly. It is the system that is the problem, not the support staff. Unity has an entire staff of the best programmers on the planet, but the worst bug system on the planet, so a replacement of the bug system is really required at this point in the game.

 

What I hate, is that after the bug is reported, there is no way of knowing if you actually sent a file with it. I'd like to know that I didn't screw that up, because I know I have forgotten in the past (usually when overwhelmed and sending multiple reports in a row).

It's definitely a waste of everyone's time to not know if your bug has been reported before. Any sort of search function would be nice.

 

I have to agree. Not being able to search for bugs and related incidents is the most frustrating thing about Unity's bug reporting system. Not only would it ease our pain as developers, but it would have the side benefit of keeping Unity honest.

 

Another thing is - if you close it, say why.
Maybe it's just a duplicate of some other bug, but you're instead giving the message "we don't care".

 

What gets me is if when sending a detailed report thats taken time to write, if it doesnt get sent for some reason (eg if using dialup the line may have dropped) the "message cannot be sent" dialouge appears, and the written message vanishes into thin air. I've already donated time to write the bug report, no way in hell am I rewriting it again. This has happened a dozen or so times to me.

AC

 

Guys,

I like what I see... You are awesome!

Keep the feedback coming.

Cheers
Nico

 

It's a small problem, but the fact that the bug reporter won't resize baffles me. The "Problem details" box is pretty tiny for what we usually need to enter in it, so I usually have to actually type my report in some other text editor, then copy-paste it in there, which takes longer and makes me not want to report bugs.

Just make that dialog resizable and I'll report bugs more often through it ;-)

 

Ya, this has to be the most annoying thing about the bug reporter. I often just end up sending an email instead of using the bug reporter because of this.

 

I say start a bug webpage the same as the feedback/requests site.
That way we can add bugs, people can vote on them and comment on them.
Unity people can tick if they're in progress or completed.
Unity will know how much certain bugs mean to people and can prioritise.
Duplicate bug reports will be greatly reduced due to the predictive part that comes up as you are typing.
The feedback site allows catagories also.
The crash reporter can send you to the site.

Sounds ideal to me.

 

One thing that always trips me up is how the bug reporter automatically assigns the first words of your bug report as the title of the bug in FogBugz. It's pretty rare that this actually makes a descriptive title, heh.

 

The biggest problem I have is the intransparency of bugs that got fixed and not. I often report bugs twice or more during different software test cycles only to find out that those are still open. Makes bug reporting not easier as you never know what got fixed and what not (except you get a direct feedback from a dev asking for more details and telling when it gets fixed).

About the bug reporter app: it is simply not at the standard of the rest of Unity software. It does for example not show any progress reports when uploading (only if you know to log in the system logs on Mac OS, but that is very user-unfriendly). The reporter is not able to recover a suspended session (like from a network shortage or whatever reason).

It also does not save the text you enter for a later use, like the AS commit dialog inside Unity. It shall also have the ability to just drag and drop files on it like screenshots, movies etc, that would make life easier as I usually don't have the screenshots of the bug or the movie stored inside the project folder which I then upload too.

Further it would be nice to have an option to exclude folders and files from being uploaded to the server. I often save a lot of extra stuff in the project folder like screenshots, concept art and whatsnot and I usually need first to clone the project folder, remove that art stuff, zip it, upload it. Lots of extra work that could be avoided.

 

I think my suggestion a few posts up would help most of your problems ("I say start a bug webpage"...)

 

I would second and third all of the above suggestions and offer another. I have used Unity\Unity iPhone Pro (for exployer) and basic editions at home that I own personally for over 2 years. I continually have to fight with and guess at what portions of Mono .NET that you guys support. You up until recently claimed Mono .NET 1.1 support and more recently 2.1 support while fully supporting neither at any point in Unity's history.

I would suggest that the best way to report bugs is in NOT having to. As QA for Unity I feel it is your job to fully realize what portions of the Mono .NET framework you support on which Unity setup and not mine. It would take a couple of days on your end to fully compile a list of what you support and what you don't on each specific Unity configuration and then make this list available to us as developers.

Edit: I would imagine the number of reported bugs would drop if this information were available. Feature support or lack of support in .Net framework isn't a "bug" it is a "feature" or lack there of so they shouldn't be in the same pool on your end. It should just be documented clearly up front.

 

Just don't collect bugs for documentation.

Allow to edit the documentation in a collaborative way. Perhaps a wiki? You will spend your time rather moderating than fixing the docs yourselves.

 

I agree completely with Martin Schultz's post.
Is neccessary an option to exclude folders and files from being uploaded to the server because the process now is long and slow.

 

After considerable experience reporting bugs, let me add one thing:

Give the bug reporter tool the "package select" ability. My projects are often too large to upload (2 GB+) in whole, but the problem can be shown in one scene which is small. If I export a package, support tells me to upload the project. Which I can't (would take several hours on my ADSL).

If I could tell the bug reporter which SCENE is buggy, and it could upload that scene and included assets only, it would help a lot.

 

How is that any different than exporting a package? You just select the scene and hit Export Package. All the required assets are included by default, for just that scene. I do this all the time and support seems fine with it.

 

Being able to add comments/files to a bug would be helpful. There are times when I don't have any clue how to repro a bug( like a crash bug ), but after investigation, I narrow down the issue. Right now, I'm pretty much forced to file a duplicate bug report once I have more information, which wastes Unity QA's people time( since they will most likely get the bug with less information first ), and wastes my time.

It would also be helpful if Unity fixed bugs before adding new features. There are unfixed bugs, like hideflags.hideinhierarchy, which have been sitting around for at least six months now. Although I realize that not all bugs can be fixed in time for each major release, that's not an excuse to not fix them ever.

 

I won't quote him again, but I support everything Daniel said in his post. The bug reporter feels confusing and a bit clumsy.

 

Upload speed in general is quite slow , I just filed a bug and it is still uploading for about an hour. I don't believe it, it just said, as I type, that the upload failed !!!! If there was an easy way to strip your assets it could be cool (like choosing textures, models, scripts only). It might be complicated to get dependencies but i think it would make thinks much faster. You don't need textures to see a problem about a rigid body. maybe to copy your project automatically to a new temp folder where with the help of a menu you could choose things to discard, but you can test also that you can reproduce the problem . Apart from being handy it might help you understand where the problem is if the error doesn't say much .

 

The problems the reporter app itself has are well known by now, if not you can dig out the recent thread on it with pretty lengthy postings by zumwalt and others.

what I see missing is a portal side of it where existing reports can be checked and where we can report too, which works similar to answers.unity3d.com, including the up and down voting, so problems that are not bugs can be down voted by users while they can vote it up if they have the bug too and add further things.

might be that this potentially isn't optimal to your side of the handling naturally ... but its clear that the black box of hell is something that gets less and less acceptable for our side as endusers as we drop stuff in without any information on its state etc at all, and that after we wasted hours to extract the actual bug, recreate it and report it although you already had 10 reports on the matter which is more than just rather annoying as time is money and its money we have to waste cause we work against an archaic bug system that misses nearly any basic point of a modern system.

Even unfuddle would kill your bug handling by an order of a magnitude ...

 

As a developer I've seen a few bug reporting systems, from the fully opaque "is anything happening" to the completely transparent "I can't make sense of any of this".

I think a good middle ground is how Adobe has opened up their public Jira. It's worth creating an account just to see.
http://bugs.adobe.com/jira/secure/Dashboard.jspa

While sometimes difficult to find the bug on this (because they are dealing with a large number of products) for a specifically designed product like Unity this would be great.

Key points I like in a public bug system:

1. A good search, so I can find if the bug has been entered before to read it's development, feedback and potentially add new information
2. QA reporters who will take sparely populated reports and populate it with more text, more clearly defining the problem in the bug. This feeds back into 1.
3. Good granularity in the "component" selection, instead of just one catchall or a bunch of internal code words that aren't easy to decipher.
4. A good reporting template with the initial comment seeded by this.
5. Publicly exposing an issue's priority, especially if you've subscribed, voted for or listed a bug. (This makes people this affects happy, and if a bug isn't moving fast enough for someone, they get an opportunity to further clarify why it's important) Allowing the community to vote for an issue lets Unity know what's important to customers, instead of having to make (potentially incorrect) assumptions. An aside, Adobe rejected adding automated getters and setters for a long time, until the entire community kept voting for it. Many upgraded (re $paid$) just for this.
6. A way to add attachments of files/resources without any arbitrary loop holes. This is especially important because many developers will make a lightweight test harness to see what composes the bug, (mostly to find a work around) and can attach this directly.
7. Simple user registration. This is a (relatively) small community and there's no reason to make this a 4 step half hour process to report a bug. Tie it to forum registration? Product registration? Nothing is more frustrating that having to struggle to register to submit an issue that doesn't do you any immediate good, but you care and want the company/product to improve over time.
8. Public viewing, private updating. So issues can be cross linked to other developers, which is especially important if there is a work around.

The number one most important thing in any public bug system is feedback from the actual company. Even if it's just a simple acknowledgement that "We see this bug, and have validated it's existence." Nothing is more frustrating than spending the time to accurately report a bug, having it seemingly disappear into the void, and two years down the road, STILL seeing the same bug. Reporting a bug, seeing it deferred or lower prioritized is more humane.

Seeing it promptly put to a higher priority, fixed, and then in the next scheduled point release is a small slice of bliss.

 

Just reply to the confirmation email you are sent. If your email contains the case number in the subject line it'll get added to your report.

Thanks,
Graham

 

Hi again,

Thanks for all your feedback. It is much appreciated. Now, let's follow up on what has been done.

Some of the issues have been taken into consideration and others haven't.
We have primed the communication by focussing on feedback to those that submit useful bugreports. (In the past we may have simply processed the bugs and closed them when they where fixed).
We have upped the attachment size (we tested project uploads up to 1.5 GB).
A progress bar was added to the uploader.
The bugreporter now (since 3.0) attaches the project folder by default, with an opt out.
Our team is growing, so we can handle more bugs (however our user base is growing even faster...).

As mentioned, not all issues have been addressed because of all the other work that was needed on 3.0 and 3.1.
Now, was there anything really critical left out? What is your thoughts compared to before the changes?

 

The most critical that is left out is the full replacement of the old bug system it self. The limits of discussion thread in it can be reached rather quickly and then no other information can be sent or seen in that thread. That has been around since the beginning of the bug report system.

 

How about this approach:

This is my first thought without analyzing beyond it to find any pitfalls.

Note: One problem I see right off hand is that there may need to be a way to obfuscate the information so as to not end up with a system that exposes one’s dirty laundry, so to speak. Perhaps I am overly concerned. Yet the way bugs are handled right now seems to have that reason as an(the) underlying premise.

Nonetheless…
The bug reporter allows the collection of system information, thus remains on the editor.
Rather than attempting to address the entire reporting process, perhaps it only picks up BASICs, the system info, and a basic title-like entry, category, and a basic description as it does now. It does not allow file uploading, nor an extensive description. Instead it instructs to visit the BUG FORUM to complete the entry.

The BASIC Info upload triggers a process at Unity that stores a keyed entry in the Unity database. (for example: a userName/date/time unique key.)

No more input into a pigeon hole style interface:
Using that key, the process at Unity then creates a NEW entry in a dedicated Bug Forum 1st level thread(to keep the current reports in the recent bubble, the stage area ).
The Owner/Creator can now type the long version of the potential bug description.
The entry created is not an official bug until more than 1 user(or an authorized advanced user) has had a chance to review the entry and further defined it(using tags as we do in other forums).

The tags basically move the bug up thru the levels, until it reaches its proper bucket, which can be the bucket of non-bugs, or the bucket of repeats(for that bug). The bucket of repeats, can still be queried along with the entry(ies) defined as the bug. One or more entries in the thread can be CHECKMARKED as the main description of the bug, with all updates/comments, etc.

The forum can be viewed/updated/discussed as any forum issues are, by all users.
File uploading based on the key stored is allowed only after the reviews have placed a clear access tag based on user permissions. (see *** below for your obvious question)

*** Users can be granted rights such as:
- Reporter (only report and comment on a potential bug, does not categorize)
- Moderator (can push issue up the levels but not all the way)
- SuperModerator (advanced users can push bugs to the proper bucket fast, even their own***).
Note: the OwnerUser permissions may need to be stored with the main entry, for special access. (Not sure what my mind is telling here, mentioning it as a reminder)

This should create a consolidation of several versions of the same bug with different inputs and scenarios as detail to help pinpointing and resolving the problem. The MARKED/main entry bubbles up to the top.
Thru the weeding process, the bulk of repeats are dropped to the non-bug, or repeat bucket, but still stored and can be queried along with the main entry should the need arise.

Flags on the main entry can be set to show progress status: received, examined, on bench, resolved, estimated date/time resolution, killed, etc.

 

im not sure if its a bug, but when i register to the asset server, all is ok. when i find something and try to download it it says i need to activate my account, and that at my email theres instructions on how to do it. problem is that theres nothing in my email. a bit help?

 

...another example of 'I am not sure this is a bug'...

When one presses the spacebar to zoom out the scene window, if subsequently click PLAY, the game window does not come on top of the scene window but the play button shows playing is on... so one goes about using the game controls and they fail to respond!?

It occurs to me, once in a while, because I do not use the spacebar zoom often, but it gets me as I try to figure out why no game controls are working, as if a compile error had occured, or the game window was not clicked(even though in this scenario no game window click is needed).

I know that in other instances the system allows windows to be under the full control of the developper so that scenarios can be explored, but this particular sequence I see as a bug in work flow. It's a snag type inconvenience... and a time eater.

is it a bug?

UPDATE: as I was proofing this entry, and reviewing some of the entries in the thread, I came to feel how much easier it would be to report bugs in a forum format, being able to see others entries, being able to type with format features, and in a window(textbox) that is not a pigeon-hole.
.

 

I love Unity, but the bug reporting process is can be one of the most frustrating aspects of working with Unity.

Always include at least a one sentence explanation as to why a bug was closed. Users can spend hours or more isolating a bug and creating a reproducible and simple test case only to have a case closed with zero feedback. Value our time as we try to value yours.

Allow us to search the bug database and add feedback to existing bug reports from other users. This way we can avoid wasting both our times by reporting a duplicate issue and we can add to an existing bug to pool any information which may help in resolving the issue more quickly. This will also help users find any work arounds that may have been reported along with the bug report.

I think those two changes will go a long way to improving things.

 

My FPS play can look around but still can't Walk around my level that I have made.Need help, I have a mac.

Some one help, fast!!

 

Yes, I'm never sure if my bug was closed because it was fixed, closed because I didn't explain it well, or just closed because the bug was old.

 

Hi
How big is your QA team? How big is your dev team? Who is responsible for writing documentation? How many people write and update documentation.
thanks for the answers

 

Unity Bug Support is awful. I've submitted 4 tickets, one got responded too. The one that got responded too was tested completely wrong. They tested a texture import issue I'm having with Unity by creating builds using the buggy texture (and then telling me the texture was indeed buggy -.-).

I love the Unity engine to death, but glaring flaws like this make a little less desirable to come back to.

 

I personally think that there should be an option to submit a bug report without all the 'fluff' that goes with it (logs, all the system info etc - especially when there all a few mb in size and take an age to go!). Alternatively an option to select the relevant stuff from those would be nice.

I've found a few bugs that are simple logic problems that don't really need any of that information to go, so for good measure I'll mention them here:

- 'Directory not found' on opening a project - the directory exists, the project opens just this lil error seems to think otherwise
UnityEditor.ValidateProjectDirectoryStructure.ValidateProjectFolder (System.String projectPath) (at C:/BuildAgent/work/6bc5f79e0a4296d6/Editor/Mono/InternalUtility/EditorApplication.cs:11)

The directory itself is on a networked drive (not the local machine); local projects don't show this so I'm pretty certain thats why!


- 'streaming of 'php?streamkey=1203912389' is not supported on this platform'. Shows up when trying to access WWW.GetAudioClip.

Not every streaming clip has the file type in the url - instead their in the first few bytes of the actual file content (which is how things like flash do it). MP3 streaming on PC/Windows complains here too.

Whilst on the subject of streaming (and although a little off topic), WWW callbacks would be much nicer than having to poll it's progress, and being able to generate AudioClips from byte[]'s would be very useful

 

Not in any order, but just off the top of my head:

The current text only pigeon-hole interface is crap.
Use a forum like interface such as the one I am typing in.
Multiple titled text boxes as needed to segregate type info.

Allow for a search with tags just like in Unity Answers(at least)

Let me decide what information to send you.
Leave the auto sysinfo collection in but add a button for me and others who wish to turn it off completely.
I know how to send you the sysinfo myself.

Provide a progress status set of flag that show with the report(at top preferably, drop down ok.)
...and odometers as needed for attached docs.(list them somewhere with the report, so know what was sent)

A staging mode and a bug mode, so others can flag the report is dup and point to the existing one.
Then reporter can either cancel request or adjust what is different.

oh! add a palm-girl who can type it for me if you have extra time(lol)!

P.S: although this may be off-topic, I would prefer that all posts in the forums that actually are advertising for tools and the such that others are cooking for the community(charging money) would be placed in a separate group/forum. I am not against the practice, just don't want to be bothered with it while I search for forum solutions.
.

 

hi, I am since several years for the third time a Defect Manager, this time for a huge project of the government. I experienced and evaluated many tools for Bugreporting. So you can have the best tool with custom attributes and so on, but it requires processing the handling of the bugs. In your case I'd suggest to have a Defect Manager, he will take care of all issues resulting. My two cents...

 

You have a support forum here and I have yet to receive help regarding this potentially major issue:
http://forum.unity3d.com/threads/96...n-when-an-instance-is-deactivated-immediately

Before you file tickets, you need support to decide if a report IS a bug.

I suggest you get a good ticketing system that Unity employees populate and then post a ticket number to the forums here if a bug was found. Make it a link so we can follow the progress.This we we either
A) Know it is a bug and can track it
B) Get some support to find the user issue.

 

I think the important part of submitting bug reports is trying to cut down on newbies thinking it's a bug but it isn't a bug. Personally I've encountered one bug I know for sure is a bug, because it doesn't occur in physx used with C++, but does occur in unity. It's a bug where compound colliders don't report an oncollisionexit even if you loop through contact points, unless all compounds have left the collider, it only reports events for the rigid body for exit (enter is fine(!))

I wasn't even aware of where to submit bugs. And if you make people more aware of where to submit, it might not be an actual bug. You'll get a lot more noise to signal from inexperienced users, so you would probably want a questionnaire people have to click through first with multi select answers so that you can quickly filter what may be genuine engine bugs and what might just be user error.

It would also allow you to generate a heat map for bug reports due to the multiple select answer process, as you are able to group reports.

 

I hear ya. But in my opinion it`s better to submit one bug too much than not enough. You can never be sure if it`s a feature, even with a 100% bug. So every bug reporter will make the experience of rejected bugs sooner or later. Maybe your different behaviour between C++ and Unity PhysX is just a different behaviour, a not yet implemented feature, and no bug. But even here, you would give needed feedback. And maybe this feedback would lead to a changing. Even when it`s no bug

It`s by the way especially newbees who have an open eye to the things where a experienced user is not longer noticing a bug, because he is already used to the workarounds. New brooms sweeps well. And the more eyes have a look at things the better the things usually gets ...

 

So. It's a year and a half after the initial post. Have you guys done anything yet?

It would be pretty awesome if you spent the money I just used to upgrade to pro on fixing bugs...

 

Just having a list of bugs along with the frequency they are reported would be handy. I'm having an issue with terrains losing some of the data resulting in the physics not functioning properly. In game, when the game is running the character controller falls through the terrain. The only two fixes that works to date, is to add a completely new terrain and delete the malfunctioning one... even that doesn't work sometimes, and the last resort is to create a new project. No fun once 10 or more hours have been expended designing a game level.

 

SystemLanguage

IOS platform does not recognize Chinese

 

My one experience with bug reporting so far is that I don't see the purpose of allowing us to report bugs at all if they aren't going to be fixed.

Someone reported a bug from back in May last year about how Screen.resolutions flat-out doesn't work on the PC while inside the editor, and as of beta 3.5 this is still broken. It was reported by someone else back in May of 2011, and I reported it again just five minutes ago.

The only way it does work is to go through the trouble of creating an all-new build and running the build. And even then, it does incorrect refresh rate reporting, with the last two refresh rates showing as 0hz.

 

It doesn't? I don't know I'm testing a game in Chinese now.

 

Any way we can get a working bug system this year? For the past two plus years I have submitted bugs without a single email response back with a case number or anything, back about 5 years ago I used to get a link that allowed me to check on the status and what I submitted, but that stopped over two years ago and no one has responded to emails about the non functional bug system for years now, just wondering if it is even going to be reviewed for a solution or if it is simply only allowed to submit a certain number of bugs then we are done.

That flaw was discovered in the bug system several years back but no one has fixed it yet.

 

There is a need to receive a response and be able to search on bug database, this last is a must.

If users we can't figure out if something it's a bug or a problem on our project then we are wasting time on both parts.

I'm not requesting a detailled explanation for every case, but at least an email response with an updated status.

Something simple as sending an email with subject: "Bug accepted", "Bug rejected", "Need more information", will motivate to keep reporting bugs and will improve their quality.

If we don't receive a response then we don't know what's happening and If the case is reviewed, so why report something if isn't reviewed?

 

What I personaly think of bug reports is that it's a completely useless feature as I haven't yet seen any of bugs fixed. I mean, seriousely - threre are tons of bugs in Unity and the stay with us for years already! What's the purpose to report a bug if it's not going to be fixed ever?