If you wanted to teach a class in state machines, defect reports would be a great case study. They have a very limited set of states and clearly defined rules for when to transition between them. They don't always touch every state, and they can have cycles, going back and forth between states. One common question with defect reports is Who Closes Out the Defect Report. Some say the developer, some say the TPM, some say the tester, but I think it's really pretty straightforward. The person who opened the report is responsible for closing it. Mike Jennings says it better than I can.
This also applies to things that aren't obviously defect (bug) reports. Consider comments in a Google doc. While they might not be labeled as defect reports they indicate an issue with the doc. It might be a lack of clarity, it might be a missed case, it might be a factual error, or something else entirely. Regardless, the comment indicates a problem. It is typically on the doc author to respond to the comment, but others with the answer can also chime in. Either way the response and/or change to the doc is there to address the "defect" in the doc. So who closes the comment, if anyone? I've seen at least four different approaches.
My preferred method is for the author of the comment to mark it as resolved when they feel the issue has been addressed. When all comments are resolved then there are no open issues. Those that want to see the comments can enable the comment threads to be shown.
Second is for the author to somehow indicate that the issue is resolved by added to the comment thread and then leave the comment open. In this way there positive acknowledgement that issues have been resolved (albeit hard to tell), but the comments are easy for everyone to view.
Third is for the author to respond to/address the comment and if the commenter has something else to say they do. In this case you're never quite sure if issues have been addressed.
Last, and the one I'll push back on every time I see it, is for the author to respond and close the comment, relying on the commenter to re-open the issue if they want. To me this is exactly the wrong way to approach it. Comments indicate an issue a customer has with the product. The only person who knows if the customer's issue has been resolved is the customer. Anything else discourages people from reporting issues and disenfranchises them. Cutting the customer out of the loop is never something we should be doing.
This doesn't mean that we always do what the customer wants or that every issue will be addressed to every customer's satisfaction. It's perfectly valid to tell a customer, "Yeah, it's not great, but this is what we can do here/now. We'll worry about your issue later." or "I don't think that's an issue because ...". but we should always acknowledge the issue and not lose track of it.