@s-roesgen > First of all it would be nice to see here some answer to Tal's comment #112, which includes some very good and valid points. done > You think that one should be silent and not complain further if it comes to certain bugs. They are marked as "won't fix" and > should not be discussed further. You do not understand the reason for any further discussion taking place? Well first design is not using "wontfix" as "we will never ever fix it" but as "it's not something we plan to address in the near futur", which often comes to a priority handling game. Now maybe we could make that clearer when closing bugs and saying the issue might be revisited in the futur but is not scheduled for the next iterations. Do you also have example where bugs got "wontfix-ed" without comments on explanation? My experience is that often there is a comment or description update going with those. One other thing worth noting is that bug suggesting a solution rather than explaining the issue are harder to deal with with design. Often users ask for something to be made similar to what they are used to without trying to explain why it's better than the currernt way or what limitation they are hitting. Change can be hard but you don't design a great experience by copying old ways, you try to focus on the problems and the best way to solve them. Yes it makes harder the transition but it should also make better the experience after that. > Well, perhaps some people, like you and the "won't fix" party, should have a look at a couple of launchpad bugs. All of them have in common that they do have problems due to basic design issues . Obviously there was much thought on design in Unity planning, and less thought on more practical aspects. There is "won't fix party", there is a ridiculisly low number of "wontfix" bugs on Unity as the stat I gave before show, we should try to stop focussing on that. And yes, lot of the current unity has issues, http://people.canonical.com/~platform/design/ points that hundred of usability issues have been identified, a good part has suggested solutions but needs to make its way to the code. The number there can be impressive but those are mostly bugs, then you hit lot of things that the design team didn't have time to properly think about or design yet. the multiscreen usage being one which just started being worked and is scheduled for this cycle. > The most important of these bugs is, in my opinion, bug 727171 Just as side note, this bug has been opened by one of the Canonical engineers working in the Unity team ;-) > Reading the comments in bug 857668 (https://bugs.launchpad.net/unity/+bug/857668) should offer some more interesting insights into the issues triggered by mere design decisions. > Further problems are described in bug 777241 and ... well let me stop here listing them all. Some of them duplicates, some of the smaller issues. Right, those are known issue and will be addressed this cycle, they didn't get worked before for a simple manpower reason. > My problem is indeed not a design decision that led to a "won't fix" position concerning certain bugs. I can get used to many design decisions. The problem is > a) how these decisions are communicated > b) on what ideas these decisions are grounded/based Some people there seem to read to much in the fact that people are just overworked and can't solve all the world software issues in a day. > On the way of how these decisions are communicated you should only read Tal's comment #112. It was said that the launcher will not be moveable because it should be tied to the BFB. Now the BFB is part of the launcher but still the decision to not make the launcher movable stays . Ergo the explanation that the BFB and the launcher should be on the same side was a lie. And I am very sorry to put it that way, but to me it is and stays a lie unless I will hear some more thoroughly elaborated explanation to the community why the decision to let it be a "won't fix" bug stays. That bug is just simply not a priority today, look at the design bugs summary and spec, there is lot of things that need to be sorted for unity to work at all for some users (like multi monitor handling), once that work is done we can look at extra flexibility and options > So, my complaints are not about a single bug. My complaints deal with communication of problems and design decisions. they deal with the way the community is treated. I am not stupid. We are not stupid. Many people have not forgotten, what the initial explanation to not fix a bug was based on. But we are treated as if we had the memory capabilities of a fly. The community engagement is broken. And that is fact. Obviously we are treated as second class citizens, who need not be informed, who need not be able to have a look at design decisions and general agendas/plans. ... No, it's just that we don't have enough people to do the work and the number of users is higher than the number of people reading and replying to bugs filed by those users, it's as simple as that