[ComputerGuru]

I’m with you 100% except you’re not taking into account what I said about this being in public and Alice not being a part of the project. Internally assigning blame isn’t the issue, it’s about the “team” facade being shattered when dealing with the outside. If you’ve accepted Charlie into the organization then from without it isn’t about Charlie or Bob, the answer should be “yes, we’re aware; a recent commit broke that functionality and we’re working on fixing it.” I’m not even talking about a dev mailing list or GitHub PR discussion, I’m taking about the specific case of badmouthing a developer to an enduser.

Imagine if Apple came out and said “yeah, that blank root password bug, it was all because of John Smith and his crap patch that caused this.”

Outsiders don’t have the same perspective as insiders. If Charlie’s commit message read “implementing the really difficult thing we talked about,” the team might be aware of mitigating factors that Alice won’t. But even without those mitigating factors, all you’ve done is badmouth your own devs to the public. Additionally, you are not considering whether Charlie is an otherwise stellar developer that has never had a bad patch before. Alice may incorrectly presume that the only reason he’s being called out is because this is a habit of his, perhaps.

[lev99]

I often compare open source projects based on what's visible on the github page.

Drama around a volunteer team in the open is a bad smell.

Edit: I'd like to explain why.

* Open source projects with lots of drama often don't attract new talented developers, and if talent happens to depend on that codebase they are more likely to fork and start a new community, or fork and not submit pull requests.

* If I need to interact with the team for pull requests or bug/support tickets I'd like to feel assured we can do so respectfully and professionally.

* If a community has drama in it I am less likely to recommend the software to a friend or blog about the software because I won't want to be associated with it. I'm more likely to stop using it and switch to a different solution.