Re: When is a 3933 experiment necessary? [Was: Last Call: <draft-farrell-ft-03.txt> (A Fast-Track way to RFC with Running Code) to Experimental RFC]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> We often pick on every suggested change and point out every possible
> flaw, with different people holding out behind different flaws, and we
> get stuck there.  There seems to be some assumption, when we do this,
> that our current process doesn't also have significant flaws.  But the
> very reason we're trying to change something is that we *already* have
> a process with flaws.
> 
> We know that no process we ever come up with will be perfect, and
> agreeing to change is a question of deciding what the flaw balance is.
> We need to allow ourselves to move from one (known, "comfortable")
> set of flaws to a new set, *if* we can come to a reasonable agreement
> that we've improved things in a useful way.

perfection is the enemy of good

and adding complexity to overcome objections is an engineer's disease

randy


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]