Need version information, please.

Sure, sorry.

rPbcd87e0e3f3756970d26d5e9c4a60e4be73ef6a6
rARC3c4735795a2963c5ddff6dceaf60122d01ca3dc0
rPHUa900d7b63e954e221efe140f0f33d3d701524aae

• There's probably one fairly narrow bug bug here: DifferentialTransactionEditor->getMailTo() likely includes resigned users but should not.
• Beyond that, when you've resigned, we should probably exclude you from getting indirect mail via a project/package? Maybe? (But what if you meant "I'm not going to review this but still want to keep an eye on it" instead of "I'm not going to review this and don't care about it at all"?)

In T12689#223076, @epriestley wrote:

(But what if you meant "I'm not going to review this but still want to keep an eye on it" instead of "I'm not going to review this and don't care about it at all"?)

Isnt that what subscribers is for?

You can't explicitly subscribe to a revision you're a reviewer for because being a reviewer makes you an automatic subscriber (and, due to a similar bug to the one here, probably can't subscribe even if you've resigned, today), so you'd need to resign, then explicitly subscribe. Also, I'm not sure we handle the other way (explicitly unsubscribe, then later become a reviewer) correctly. These are tractable.

However, this stuff has been in HEAD for like 6 weeks or something and no one else has complained, so it's possible that almost everyone using "Resign" means "I still want email normally, just get it off my dashboard", and that jumping through all the hoops to implement this behavior in a more sophisticated way would actually make the product sort of worse in practice, even if it was more consistent/flexible.

I think we probably should still do it anyway, there's just some product subtlety here which wouldn't be present if the existing behavior was unambiguously undesirable (e.g., throws an exception and does not resign you).