[greenrd]

Reverting someone's commits "silently" (inasmuch as you can do anything silently in git!) is any of those? That's interesting, because my commits were once "silently" reverted at a previous workplace and then when I queried it, it was explained that I was the one in the wrong.

Because I had made a commit without discussing it first and without understanding what I was doing.

(I would have discussed it first, but the developer concerned was on holiday at the time.)

What I'm saying is, there's a possibility that it wasn't unprofessional.

Some might argue what was unprofessional at both employers (GitHub and my previous one) was not having an iron policy that all commits must be code reviewed by another person. But that's a policy issue.

[rsynnott]

There's a _possibility_ that it was just that suddenly after the failed come-on, her commits suddenly needed a lot of reverting (though you'd think Github, of all companies, would have decent policies on communicating on changes; silent reversion is not normal and is likely to cause a lot of confusion).

However, it allegedly started happening _after_ the failed come-on, which would make it retaliatory. That's unprofessional, and probably amounts to gross misconduct.

[Crito]

> "However, it allegedly started happening _after_ the failed come-on, which would make it retaliatory."

That would make it possibly retaliatory. It remains possible (although I would not say that I consider it likely) that there were legitimate technical justifications for reverts made after the rejection, and that the sequencing of those two events was entirely coincidental.

If I were management at github, I would grill the employee who reverted those changes for a technical justification for the reverts. If the justification seemed tenuous or strained, I would fire them on the spot. I would however make sure to grill them before firing them, as it is not certain that there was no legitimate technical justification.