Richard,
A few things that people who suggest a complete replacement of tools should think about:
- frequently introducing yet another learning curve doesn’t shorten the overall learning curve for anyone. If there is any benefit in it for anyone, it is that it tends to level the
playing field. I doubt there is any way to determine definitively whether that is a good thing, or a bad thing. YMMV.
- wholesale replacement of tools has a direct analog in many other areas. Imagine for instance if, in trades (wood working, metal working, etc.), someone suggested obsoleting the tools
used by experienced craftsmen (ignore any seeming gender specificity) in order to (theoretically) simplify the learning curve for apprentices. The theory behind any such move would be that this would allow apprentices to more quickly become qualified tradesmen
– but that theory would require time to validate and would likely severely impact skilled production in the meantime.
- in this particular work (i.e. – standardization) – as with a number of other areas – “tools” is actually the area with the least significant learning curve. A far more significant
learning curve is associated with learning the many things that have been tried, and determined to be unworkable, over a time period far greater than the tools learning curve for even the most casual tools user.
I suspect that a prolonged discussion of the benefits of introducing new tools is misplaced effort.
--
Eric
From: ietf <ietf-bounces@xxxxxxxx> On Behalf Of
Richard Barnes
Sent: Wednesday, July 10, 2019 11:17 AM
To: adrian@xxxxxxxxxxxx
Cc: Julian Reschke <julian.reschke@xxxxxx>; IETF Rinse Repeat <ietf@xxxxxxxx>
Subject: Re: Things that used to be clear (was Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.)
You're absolutely correct that any tool comes with a learning curve. The trick is "bringing the mountain to Mohammed" as it were; using tools for which many people have already climbed the curve. By definition, anything that is IETF-custom
is brand-new learning curve for a newcomer.
Is it really that hard?
Even crusty old idiots like me have worked out how to use an editor to make XML that is acceptable to XML2RFC. I doubt that I am clever or more talented than
Fellows of major engineering organizations.
All tools (even github) require to be learned.
Replace tools with better tools, by all means.
But don’t make changes for personal preference: that way lies unending debates about whose preference is best.
Thanks,
Adrian
From: ietf <ietf-bounces@xxxxxxxx>
On Behalf Of Richard Barnes
Sent: 10 July 2019 14:57
To: Randy Bush <randy@xxxxxxx>
Cc: Julian Reschke <julian.reschke@xxxxxx>; IETF Rinse Repeat <ietf@xxxxxxxx>
Subject: Re: Things that used to be clear (was Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.)
I'm glad it works for you. The non-IETF-habituated new authors I've worked with have found it mystifying. Including everyone from junior engineers to Fellows
of major engineering organizations.
As Christian says, our continued attachment to bespoke tools is a barrier to getting new work in the IETF, and thus detrimental to the long-term health of the
organization.
On Wed, Jul 10, 2019 at 9:47 AM Randy Bush <randy@xxxxxxx> wrote:
>> Tooling is just one of the problems with XML2RFC. The real issue is
>> that XML2RFC is completely specific to the IETF. This translate into
>> training ...
> It also has been optimized for the production of RFCs. Also note that
> many changes in the v3 vocab just align the language with HTML (lists
> and tables come to mind).
from an xml non-lover:
xml2rfc rocks! it produces the baroqe, designed by committee, internet
draft format from input which i can easily produce in my text editor.
and the support, maintenance, and responsiveness of the tools team is
simply stunning.
[ and for the poster who wished for a gooey, there is one ]
thank you!
randy
|
