Hi, is there any update in the case?

I'm not 100% sure on what you mean. 'Done' is when a Story is completed in the sense that it meets the test criteria (defined in the field 'Test').

...and satisfies all assigned qualities.

@Krzysztof: What else could be defined by the team?

In Test field we fill acceptance criteria that comes from so called "business". During implementation we should be in line with some rules that are agreed within a Team for all implementation tasks. These rules should be respected by all TM. Rules defines acceptance criteria of code quality. Here is example of part of our DOD of Task:

1. Source code and tests are commited in SCM repository
2. Source code contains javadocs for class, all public and important private methods
3. Source code is in line with defined checkstyle
4. Metrics job on Jenkins do not find any warnings in source code
5. All business calls are registered in BOR (Business Operation Registry)
6. Crucial operations are logged by INFO level
7. Unit tests are written for all new/changed components. In case of change tests are updated.
8. Integration tests are written for all business methods.
9. Build job on Jenkins is successful and all tests pass.
etc...

and shorter list we have for Story
1. All tasks pass DOD
2. Story has been verified by Developer with code review
3. Story has been verified by Tester
4. Story meets test criteria.
5. All raised bugs are fixed or are marked as not blocking story by PO.

These TM contract is binding the whole team during software development process. I rather see it as some "internal requirements for code quality" and these qualities are not intended to be assign to every task or story. They do not differ between tasks and in my opinion it would be useful if there would be some place for such rules in Kunagi. They can be treated as some checklist before marking Task or Story as Done or Accepted.

Off topic: I do not receive emails for raised issues or new comments (I fill email address every time) and have to fill directly issue URL and check from time to time if there are any updates. Is it normal or I did sth wrong? I can remember that some time ago I did receive email with notification about some other topic.

Ok, I understand what you mean. I think this is nice-to-have for you, not urgent. We'll think about this.

As for the e-mail notifications, this is a thing we currently do manually. I have created an issue for that (iss718).

Yes, this is nice-to-have but I think it is good to have such contract written down in Scrum. Some time ago when we have been working without SCRUM, and the quality of software was usually measured by number of raised bugs, the quality of code depended from developer to developer. What is more the code look was not consistent and things that should be done in common way were not done that way. I can see dramatic change of code quality after we have agreed DoD and introduced DEV verification for each story. I understand self organizing in scrum as also to be in line with commonly (in team) elaborated set of rules.
In case of teams that do not have such definitions or have but not written down, they might to think, oh yeah, good idea to write down some general quality acceptance rules.
There could be also "DoD" link or tooltip near "Done" button and Story "Accept/Decline" buttons to remember about agreed contract and to make it easy to take a look there.

I have the impression that this feature request still covers a rather special case in the sense that -- should we implement this feature -- a minority of people would use it. Not because it's a bad idea, but because there are various possibilities to do that. In smaller (or less organized) this might be done "mentally". In companies, there might be company-wide criteria published somewhere else, or people might have printed out such rules.

In the end, we would need to alter the UI by an element that is always there, but not always used. I'd generally try to avoid such a situation.

What about making that a Wiki page? I think that would be as good as having such a definition hidden away somewhere on top of the Qualities page. If we had such a feature, the information would need to be accessible from somewhere where it's useful.