Re: "why I quit writing internet standards"

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

 




AB

One thing I've stumbled across as WG Chair and Attempting to shepherd documents through the process is if you're not vigilant, that some comments or questions get lost in the process.

I like where httpbis WG has gone in using github for tracking issues raised during the document process. I think it has two useful cases: 1) when working with other groups outside IETF, it presents a nice 'neutral spot' for collaboration, and 2) their issue tracker is more lightweight and robust than the existing tools.

I think Ted's comment is right - we innovate when some group tries something to see if makes them more productive.

tim

On 4/14/14, 12:17 PM, Abdussalam Baryun wrote:
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.






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