Rather, I think the important thing is that meta-level discussions of how social sanctions work shouldn’t be generated by backward-chaining from an ambiguous case.
I think I disagree with this. When a social sanction is born of a particular case, I think it is quite important to actually have that case as a part of the discussion. First, this means the social alliances are in the open instead of hidden, second, this means that discussions over what principles actually bear on the situation becomes on-topic as well.
I think also it’s quite difficult for people to think about tradeoffs in the abstract; “should annoying people be allowed at meetups?” is different from “should we let Bob keep coming to meetups?”, and generally the latter is a more productive question.
The other option is making social sanctions preemptively, but there it’s not clear what violations might be possible or probable, and so not making rules until they’ve been violated seems sensible. (Of course, many rules have been violated before in human experience, such that in forming a new group you might import existing rules.)
I think I disagree with this. When a social sanction is born of a particular case, I think it is quite important to actually have that case as a part of the discussion.
Clarification: what I meant is that it’s better if the rules are created in a context where there are no cases pending for the rules to bear on; ie, I’m not objecting to admitting that a rules-discussion is about a specific case that it would bear on, but to it actually being about a specific pending case.
I think also it’s quite difficult for people to think about tradeoffs in the abstract; “should annoying people be allowed at meetups?” is different from “should we let Bob keep coming to meetups?”, and generally the latter is a more productive question.
I think discussing the latter question is less likely to produce the right result, though.
Clarification: what I meant is that it’s better if the rules are created in a context where there are no cases pending for the rules to bear on; ie, I’m not objecting to admitting that a rules-discussion is about a specific case that it would bear on, but to it actually being about a specific pending case.
This is how things are often done in law, tho; I think “common law” is a pretty good way to grow a body of rules. You can then abstract out principles and refactor. It’s not clear yet how much of this is about cost minimization; one of the benefits of deciding cases as they come up is you only ever need to decide as many cases as happened, which is not true if you try to decide cases before they become pending.
I think I disagree with this. When a social sanction is born of a particular case, I think it is quite important to actually have that case as a part of the discussion. First, this means the social alliances are in the open instead of hidden, second, this means that discussions over what principles actually bear on the situation becomes on-topic as well.
I think also it’s quite difficult for people to think about tradeoffs in the abstract; “should annoying people be allowed at meetups?” is different from “should we let Bob keep coming to meetups?”, and generally the latter is a more productive question.
The other option is making social sanctions preemptively, but there it’s not clear what violations might be possible or probable, and so not making rules until they’ve been violated seems sensible. (Of course, many rules have been violated before in human experience, such that in forming a new group you might import existing rules.)
Clarification: what I meant is that it’s better if the rules are created in a context where there are no cases pending for the rules to bear on; ie, I’m not objecting to admitting that a rules-discussion is about a specific case that it would bear on, but to it actually being about a specific pending case.
I think discussing the latter question is less likely to produce the right result, though.
This is how things are often done in law, tho; I think “common law” is a pretty good way to grow a body of rules. You can then abstract out principles and refactor. It’s not clear yet how much of this is about cost minimization; one of the benefits of deciding cases as they come up is you only ever need to decide as many cases as happened, which is not true if you try to decide cases before they become pending.
On the other hand, clear systematic codes may reduce the # of cases that come up (or evaluation time per case) by reducing ambiguity.