In your first example: you are not necessarily "the person most familiar", and I don't think that's the assumption. You are, however, likely (to some degree) to know who should be contacted to resolve the real problem.
In your second: If you changed a value in a configuration file and it triggered an exception somewhere, many people would say you are at fault for not testing your change.
Most places I've worked there's a simple rule: whoever last touched the code that broke is responsible for getting it fixed. That isn't meant to be taken literally in that I must actually make the code change myself. It means that it can be assumed that if I'm touching some code, I'd better be familiar with the code I'm touching. If that means I delegate the fix to the original author, then great: It's still getting fixed. If I can delegate to someone who's better suited to make the code change, that's OK too. If not, I make the fix. In any case, If I'm changing a line of code, you can assume that I'll know what action to take if that change breaks something. If I don't, I shouldn't be allowed to make the change in the first place.
In your second: If you changed a value in a configuration file and it triggered an exception somewhere, many people would say you are at fault for not testing your change.
Exactly. However, the exception will likely be thrown from somewhere in the network stack, not from a config file, so whoever last modified the error checking code in the network stack will get an email instead.
In your second: If you changed a value in a configuration file and it triggered an exception somewhere, many people would say you are at fault for not testing your change.
Most places I've worked there's a simple rule: whoever last touched the code that broke is responsible for getting it fixed. That isn't meant to be taken literally in that I must actually make the code change myself. It means that it can be assumed that if I'm touching some code, I'd better be familiar with the code I'm touching. If that means I delegate the fix to the original author, then great: It's still getting fixed. If I can delegate to someone who's better suited to make the code change, that's OK too. If not, I make the fix. In any case, If I'm changing a line of code, you can assume that I'll know what action to take if that change breaks something. If I don't, I shouldn't be allowed to make the change in the first place.