Who is responsible for adding the bug report

When I see this headline, my first reaction is that I'm against the boss. Because as a developer, what I hate most is someone pointing at my nose and saying, "It's your responsibility, because the code you wrote is out of the question." I usually argue, even sometimes I get angry. But how can sufficient evidence be used to justify such an approach? Well, I really don't have a system to think about it. So, when I saw a discussion like this, I was instantly attracted, and the power of the masses is huge, the masses of the thought can bloom, I can learn a lot of knowledge from the discussion, and with these arguments, when I will inevitably encounter accusations in the future, then at least in my heart can find a lot of comfort. Let's take a look at how the founders of this great discussion described the problems they encountered:

In the recent system reform, the boss wants to add the "Who's responsibility" item to our bug tracking template, which he believes will improve the programmer's sense of responsibility (there are already places on the tracking list that indicate which function/use case the bug belongs to). I think this will hit the programmer's morale, cause people to blame each other, and for some of the problems due to the needs of the bug is not filled.

Is there any other effective way to refute this? Who knows where there are articles on this subject to refer to? I want to see this for the team's colleagues and bosses. I think this culture is unacceptable and I hope to stop it before it is implemented. I am very grateful for any suggestions.

Some netizens pointed out that the disadvantage of doing so is:

If someone thinks that the "whose responsibility" item is to be filled with his or her own name, he will not report the bug. This causes the team to reduce the number of bugs.

My favorite answer to such a question is the following:

The first thing I have to do is ask your boss what he wants to do to solve the problem. There are a lot of apparently better ways to solve the problem he's trying to solve.

Do you really need someone to stand up for a thing? If so, your boss may have a problem somewhere else. A good workflow requires a lot of people to participate in, before the software is officially released, it needs to go through analysts, developers, code inspectors, testers. If you don't go through all of these steps, developing strictly following these steps will be the best solution to your boss's problem. If you have already followed this process, which individual should be held responsible for this? Perhaps no one should, perhaps should condemn the legacy of these historical code.

Let the people behind the discussion, blame each other will cause very bad consequences, do not arbitrarily to smear black spots, once done it is difficult to recover. This will not solve any problem. Few people deliberately make mistakes. Your boss should reflect on himself and see what the problem is, and see how it can be made to happen again.

When you do this, you can see clearly that if someone is making a mistake, it's probably a completely different question.

But the most popular answer on Stackexchange's website is the following:

Tell him that this layman's layman's name for the source of the problem that the insider is talking about (if there is no specific item to describe this, it will usually be replaced with a comment).

You can search the Internet for software bug root analysis and so on, you can find a wealth of information to prove your views 1, 2, 3, 4, ....

... The root cause of a software bug is usually not on a single developer (especially when filling in this) ...

This clearly explains why "the root of the problem" is professional, and "whose responsibility" is unprofessional. It's good to be able to explain personal responsibility, but sometimes the root of the problem arises in the development team "outside."

Tell your boss that if you need to identify a person who is responsible, the "problem root" item should be written like this: "The coding error was submitted by Bob, the version number is 1234, and Jim omitted the error in the code review, and the review number is 567". The purpose of the "problem root" item is to document such content, including some reasons outside the development team.

For example, if a bug is caused by hardware (the person who is blamed for buying/testing hardware outside of the development team), the problem can be well described with "root cause", and "whose responsibility" leads to a problem-tracking thread interruption.

This can also be documented for errors caused by people outside of other development teams-test errors, requirements changes, management decisions, and so on. For example, if management decides not to invest money in preparing disaster-response hardware, it would be meaningless to fill out "which Programmer's responsibility" in the event of a power outage in the data center.

Have you ever met anything like this?