What are the policies for importance?

At least for 6.1 the answer is in http://doc.openerp.com/v6.1/contribute/11_bug_tracker.html#bug-qualification

"""
Assessing the importance of a bug is a difficult and often subjective task. In order to have common criteria, we propose the following definition for the severity levels on Launchpad bugs

        Critical: security issue (e.g. system compromised or arbitrary code execution possible), or system completely unusable, for many users. Any kind of data loss.

        High: major part of an application not working correctly and blocking for many users: like the impossibility to display Sale Orders for all users (not just for a peculiar setup, but in most cases)

        Medium: a minor part of an applications not working correctly (not really blocking), or a major feature not working for few users only or for a specific configuration only.

        Low: the rest, mostly usability issues (eg. presentation/layout issues) that don’t prevent to use any of the features.

        Wishlist: nice to have features/patches, propositions to enhance/modify the current logic.
"""

Hello Gilles,

Bug importance is decide base on the Issue. which is list out in following way,

Low : when Issue is related to the usability. which treat as low. for eg. Typo Issue, layout problem..etc

Medium: Minor part of an applications not working correctly (not blocking), or a major feature not working for few users only or for a specific configuration only which treat as medium.
for eg. Traceback or error, rights problem...etc

High : Major part of application not working and blocking the flow. for eg. like the impossibility to display the Sale Order in form view for any users.

For more info : http://wiki.openerp.com/

Thanks!

Hello!

The BIG problem is the assessment. OpenERP has very different ideas of what is important. Just a few examples

functions fields can neither be selected not sorted
o2m (in v7) can not be sorted.

this is not important as long as there are only a few records, but becomes a huge problem if the user has to deal with hundreds of records.

Also,

IMHO, in order to warranty that upgrading to a new major or minor or patch release of OpenERP is a benefit, I think a basic policy should be to automatically assign a "High" importance to any bug that is a regression (something that used to work that doesn't work anymore).

Almost everybody in the software industry treats regressions as priorities, but NOT OpenERP SA which always think they do everything better than the established norm, but which is sadly rarely true IMHO.

IMHO if we don't offer this kind of "adherence with the past" warranty what we have is just CHAOS: upgrading will bring you fixes and make regressions appear randomly. If you are lucky it's a net benefit, but if you are out of luck you can loose a lot just by running bzr pull.
Because of that unassuming policy one cannot just do bzr pull once in production without planing many hours of expert bug hunting (= cost). Or that is, this is a vicious circle because then less people update automatically so less regressions are found by the community and hence the costs of upgrading explodes over the time and everybody ends up loosing time and resources that would be used better in engineering the ecosystem instead of eternally debugging it.

It's a very simple policy to adopt and IMHO the benefit would be huge. But if they think they do it smarter... Well in any case, community and customers are the judge.