On Wed, May 15, 2019 at 06:26:48PM -0400, Ted Lemon wrote: > However, we could have better tooling for doing document markup. > E.g., Google Docs has a suggesting mode, where I can go in and edit a > document, and you see my edits as suggestions that can be either > accepted or deleted. Inventing a new tool for doing this is probably > too much work for the IETF to be doing, but this is a much better way > to do document markup. Better tools for OLD/NEW text suggestions would be nice. I remember Stephen Kent using PDFs to share commentary. That was particularly difficult to use, oddly. Git* hosting services might work better, especially if authors commit .txt and/or .unpg renderings along with .xml sources and .html renderings, provided there's enough archival functionality. > The question is, how to tie it to the mailing list discussion in a way > that is useful and understandable? A bog stupid option is to just > use diff(1): edit the XML, and send us a diff. Would be nice if the I think it unlikely that reviewers will do this. They might be more inclined to edit unpaginated text renderings of the XML (I would be). > diff could be annotated, and I think it can. Why don’t we do this? Because it's difficult to intersperse commentary with suggested edits unless you do all of it in the latter form? > We’d have to make sure the MUA didn’t mangle the diff, but I think > that’s a tractable problem. Well, if you expect XML diffs, then you expect a PR. Maybe we should just move wholesale to Git* hosting services. I, for one, would consider that a loss. I recently had to collate code review commentary from a large code review on GitHub, and it was unpleasant -- I resorted to saving all the e-mails in an mbox and editing that, though perhaps I should have just built tooling aroun the GitHub API. E-mail has warts, but decades since the first RFCs, it mostly still works for us. Nico --
