I was thinking of why many quit reviewing adopted IETF drafts (or even quit
participating). In my situation there is a draft adopted in 6Lo WG and
still the author does not answer my question reminder, and it may make me
quit reviewing as well. I think IETF does not have problem of
participants quit to write but participants quit to review and contribute
more into drafts.
AB
On Monday, April 14, 2014, George, Wes wrote:
I’m surprised that no one has sent this out yet:
http://gigaom.com/2014/04/12/why-i-quit-writing-internet-standards/
"Summary: After contributing to standards organizations for more than
seven years, engineer Vidya Narayanan decided it was time to move on.
Although she still believes that these organizations make the Internet a
better place, she wonders about the pace of change versus the pace of
organizations."
My thoughts-
There are some nuggets of truth in what she says in this article, and in
some of the comments. I think that the problems are real, so there’s value
in taking the criticism constructively, despite the fact that the author
chose to focus on the problems without any suggestions of solutions.
"while the pace at which standards are written hasn’t changed in many
years, the pace at which the real world adopts software has become orders
of magnitude faster."
…
"Running code and rough consensus, the motto of the IETF, used to be
realizable at some point. … In the name of consensus, we debate frivolous
details forever. In the name of patents, we never finish.”
…
"Unless these standards organizations make radical shifts towards
practicality, their relevance will soon be questionable.”
I don’t have too many big ideas how to fix these problems, but I’ll at
least take a crack at it in order to spur discussion. My paraphrase of the
problem and some discussion follows.
- We’ve lost sight of consensus and are too often derailed by a vocal
minority of those willing to endlessly debate a point.
Part of the solution to that is reiterating what consensus is and is
not, such as draft-resnick-on-consensus so that we don’t confuse a need for
consensus with a need for unanimity. Part of the solution is IETF
leadership helping to identify when we have rough consensus encumbered by a
debate that will never resolve itself, without quieting actual disagreement
that needs continued discussion in order to find a compromise. I don’t have
good suggestions on how to make that second half better.
- We don’t have nearly enough focus on running code as the thing that
helps to ensure that we’re using our limited cycles on getting the right
things out expediently, and either getting the design right the first time,
or failing quickly and iterating to improve
The solution here may be that we need to be much more aggressive at
expecting any standards track documents to have running code much earlier
in the process. The other part of that is to renew our focus on actual
interop standards work, probably by charter or in-group feedback, shift
focus away from BCP and info documents. Perhaps when considering whether to
proceed with a given document, we need test as to whether it’s actively
helpful/needed and ensure that we know what audience would be looking at
it, rather than simply ensuring that it is “not harmful” and mostly within
the WG’s chartered focus.
Thanks,
Wes George
Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------
------------------------------
This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely
for the use of the individual or entity to which it is addressed. If you
are not the intended recipient of this E-mail, you are hereby notified that
any dissemination, distribution, copying, or action taken in relation to
the contents of and attachments to this E-mail is strictly prohibited and
may be unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any copy of
this E-mail and any printout.