On Jul 18, 2008, at 6:03 PM, SM wrote:
> Hi Lisa,
> At 16:17 18-07-2008, Lisa Dusseault wrote:
>> Or tell me if you have these concerns, or bring specific issues up
>> publicly. It's too easy for guidelines to become rules, tools to
>> create de facto rules, principles to become restrictions, loose
>> consensus for specific cases to get applied as globally strong
>> consensus. Organizations like the IESG accrete rules no matter who's
>> in the IESG. Anybody play Fluxx? We need the rule reset card!
>
> I'm surprised that you wrote that. :-)
>
> Most forms of governance reach the stage you described above. Dave
> posted a comment about whether the sorts of changes asked may be
> symptomatic of an underlying disease. Is the situation so bad that
> even common sense cannot prevail? Time will tell.
>
>
> If I'm not mistaken, bodies like the IESG are not there to create
> rules. It's the community that makes the rules based on consensus.
> Quoting Dave Clark:
I meant to say that the IETF accretes rules no matter who's in the
IESG and I completely agree that the community makes rules based on
consensus.
Ahem. Not to put too fine a point on it, but a few of us, myself included, have
consistently pushed back against this accretion. Sadly, most of the time I, and
I suspect most others, have been unsuccessful.
One thing that contribute to this accretion is narrowness of view. Say a couple
of documents come along that happen to share a problem. Why not make a rule to
address that? Seems quite in line with our general goal of trying to produce
the best documents possible, right? But while such "solutions" may address the
immediate problem, we almost always fail to consider the long term effects. We
are now up to out proverbial asses in a hodge-podge of rules, guidelines,
checklists, mandates, and who know what else. Even the IESG is now having
trouble keeping all of it straight. (In fact some would probably say that the
entire 2821bis fiasco is an example of the IESG's failure to keep up.)
Even worse is the fact that quite often the rules we make fail to actually
solve the problem they are intended to solve. This is in part because we're
good at solving engineering problems but our expertise in solving human factor
problems is, um, limited.
A good example of this is the I-D cutoff which we're dissuing right now on the
main IETF list. Irrespective of how important you think having a stable set of
documents prior to a meeting is, the fact is people have routinely routed
around what they perceive as the damage this restiction causes simply by
posting revisions elsewhere and calling people's attention to them.
But worst of all is the inordinate fondness many people seem to have for all
this dreck we've amassed around ourselves. I confess to a considerable degree
of pessimism that anything is going to change, so much so I rarely if ever
bring these sorts of things up any more. To be blunt, I'm going to have to see
some significant bit of forward progress somewhere before I'll be willing to
expend any effort on hashing out some reforms.
Ned