Sam Hartman writes:
I'd like to understand why changing the rules in the middle of a
process is a bad idea.
They aren't rules if they can be changed even as they are being
applied. If you want to make rules, you have to be willing to abide
by them. Changing the rules even as they are applied is equivalent to
not having rules to begin with (although I realize this is precisely
the unstated goal for some people).
It should not be the case that if you collect sufficient evidence
you can get someone banned from a mailing list. You have a right to
expect that if you collect sufficient evidence of an administrative
problem like a problematic individual on a mailing list, this
problem will be solved in some way. You don't have a right or
expectation to demand a particular solution. If for example the IESG
successfully managed to convince the individual to clean up their
act, you don't have a right to be disappointed that a PR action was
not approved. (If the IESG claims they have convinced the individual
to clean up their act, you may well be dubious about whether this
claim is valid.)
An alternative is to do nothing, which in the long run is the least
disruptive and wasteful of resources. All "problematic individuals"
are nothing more than one person irritating another, and if people
cultivate tolerance instead of wasting their time bickering like
schoolchildren, the overall result is greater productivity and
flexibility for all.
In particular I'm having a hard time finding an ethical or logical
reason why we would not want to approve a process change that allows
a lesser sanction for behavior that is already prohibited. Can you
help me understand why that specifically would be a bad idea?
Just because it is a change allowing a lesser sanction doesn't mean
that it justifies setting the precedent of changing the rules in
transit.
Now, there is one case where I can see a concern. If we are concerned
that the behavior may not be sanctionable today then what we are doing
might be problematic. We could make an explicit determination that
the behavior was currently prohibited before deciding to apply the
lesser sanction. Some people might question whether we could isolate
the two calls enough to make that decision.
Or we could spend this time working on the real tasks of the group
instead of whining about who should or shouldn't be banned.
Every mailing list I've ever encountered is this way, constantly
degenerating into personal attacks and attempts to censor and ban
anyone who isn't sufficiently popular or well placed. Don't people
ever grow up?
So I agree that a solution open to less question is to refuse to apply
a sanction, create a process change and wait for prohibited behavior to
happen again.
Why not just drop the whole thing and pretend nothing ever happened?
Then the group can get back to business. I know that business isn't
nearly as much fun as goofing off with bans and censorship and
arguments about bans and censorship and arguments about arguments
about bans and censorship, but it _is_ the nominal purpose of the
group, isn't it?
I think that if there is general agreement in the community that a
lesser sanction, were it available, would be adequate to solve a
problem, but we apply a greater sanction because that is the only
tool our process permits, there would be a claim for relief under
section 6.5.3 of RFC 2026.
Or maybe a temporary estoppel motion for ad hoc pro tempore injunctive
relief under subparagraph (b) of section IIa of codex 4 of Section
4.1.3.15/C (as amended) of RFC 4299182.
You know, just writing ever more complicated policies and procedures
doesn't make them useful or valid.
So, if the community decides that we need to avoid a sanction in some
specific case so we can change the process, I can agree with that
decision. If we choose to apply a sanction we agree is too great
simply because it is the tool we have, I look forward to a successful
appeal of our foolishness.
Perhaps just stepping out of the sandbox and getting back to work
would serve to eliminate the foolishness. I'm not holding my breath,
though.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf