Design choices around user attribution

In many software applications we often have to attribute actions to specific users. For example, we might attribute a comment left on a blog post to whoever wrote it. It's important this is done thoughtfully, to avoid confusion and, in some cases, inappropriate blame.

When adding a user attribution somewhere in an app, a (perhaps slightly blunt, yet broadly functional) razor one might apply to is to ask two different but related questions:

1) Would the user we're attributing this action to be happy with the way in which we are doing it?

2) Will this cause confusion for any users who are reading the attribution?

I collected a couple of examples based on real world situations I recently encountered. None are particularly egregious, I just thought they were handy references.

Example 1: email sender

• A service sends out emails to your users. If you need an example, think of an e-signing platform which notifies users that their electronic signature has been requested for various legal docs.
• The emails are actually sent from something like address@vendor and, though it doesn't exactly mask this fact, it also provides your (actual or business) name as the sender name.
• So, from the receiver's perspective, it may seem like the email came direct from you, and they may even hit reply and dash off an email of their own, questioning something about the doc they were asked to sign, expecting it will land in your inbox.
• Of course, it won't: it will go to address@vendor instead.

The intentions here on the part of the third party service are probably good—we're not describing a phishing attack (though there are similarities, certainly)—the thing is that the design choice has led to confusion and has introduced a potential blocker, however temporary, for communication between you and the recipient.

Even if the service auto-forwards replies to mitigate this, one could question whether the recipient would actually want that service to be able to see a message that potentially includes private or sensitive information.

Example 2: GitHub PR closures

• Imagine we are working in a repository with a branch named enhanced-engine.
• A contributor submits a pull request, with the above as its base branch.
• At some point a maintainer decides enhanced-engine is a dead end (though, the reason doesn't matter too much) and closes the branch.
• Any open PRs using enhanced-engine as their base branch will then be closed automatically.

This is quite reasonable: if the base branch doesn't exist, those PRs cannot be merged. What's potentially a little problematic is the way GitHub describes what happened. It will say:

Maintainer A closed this x days ago.

Now in fairness, at time of writing, it also includes a note above this one which states that the base branch was closed ... though I'm a little unsure if it always did this. The key point, though, is that it reads like the closure was a direct and explicit user action. In fact, it was really more of a side-effect. I think it would be a lot clearer to everyone, especially in a world where we're all rather busy, to describe this scenario using language like:

The base branch for this PR was closed on (date) by (user). For that reason, this pull request was closed automatically.