3 ms·

Fraud is very different from murder, and I understand why someone would be worried about accepting contributions from a known fraudster. I would not give their

by Sephr 9y ago

Fraud is very different from murder, and I understand why someone would be worried about accepting contributions from a known fraudster. I would not give their contributions extra attention (you should be suspect of all changes, regardless of the author) and I would not ban them from contributing unless they became disruptive or subversive to the project. They served their time; you don't need to punish them further. They are probably even less likely to commit fraud when their employer is aware of a previous fraud conviction. The worst fraudsters don't come with a "convicted of fraud" warning—they have evaded being caught and will seem just like any other contributor.

mannykannot 9y ago
> They served their time; you don't need to punish them further. It is not about punishing them, it is about reducing the risk of others. Having served time is, at best, no indication of whether a person will revert to their former behavior. > The worst fraudsters don't come with a "convicted of fraud" warning—they have evaded being caught and will seem just like any other contributor. This is no reason for not using what information you do have. Note: I see that you have edited your original post to address these points, but I think they still stand, as expanded on in the continuing discussion below. Your statement "they are probably even less likely to commit fraud when their employer is aware of a previous fraud" seems to be in agreement with what I have been saying.
- Sephr 9y ago
  It's a reason to be equally suspicious of all code changes regardless of the publicly known reputation of a contributor, as it always comes down to the code itself.
  - mannykannot 9y ago
    You are still arguing against using the available evidence. You never have the time and resources to fully validate anything of use, so you have to use your judgement as to how best to go about it. If you learn that a person responsible for some aspect of security has been found guilty of defrauding his church's charity drive, it would be prudent to take a second look at his code.
  - watwut 9y ago
    Absolutely. Then again, code review is never perfect and it is easy to miss hard to see cosequence of something subtle. Especially if I tentionally hidden. So, trust matters. If you have track record of doing such things, then accepting your pull request comes with higher risk.

by Sephr 9y ago

mannykannot 9y ago

> They served their time; you don't need to punish them further. It is not about punishing them, it is about reducing the risk of others. Having served time is, at best, no indication of whether a person will revert to their former behavior. > The worst fraudsters don't come with a "convicted of fraud" warning—they have evaded being caught and will seem just like any other contributor. This is no reason for not using what information you do have. Note: I see that you have edited your original post to address these points, but I think they still stand, as expanded on in the continuing discussion below. Your statement "they are probably even less likely to commit fraud when their employer is aware of a previous fraud" seems to be in agreement with what I have been saying.

Sephr 9y ago
It's a reason to be equally suspicious of all code changes regardless of the publicly known reputation of a contributor, as it always comes down to the code itself.
- mannykannot 9y ago
  You are still arguing against using the available evidence. You never have the time and resources to fully validate anything of use, so you have to use your judgement as to how best to go about it. If you learn that a person responsible for some aspect of security has been found guilty of defrauding his church's charity drive, it would be prudent to take a second look at his code.
- watwut 9y ago
  Absolutely. Then again, code review is never perfect and it is easy to miss hard to see cosequence of something subtle. Especially if I tentionally hidden. So, trust matters. If you have track record of doing such things, then accepting your pull request comes with higher risk.