OK, not so private. But also just the same question as in my original message....
-Ekr On Wed, Apr 16, 2025 at 1:28 PM Eric Rescorla <e...@rtfm.com> wrote: > [Private] > I do get that the RPC is doing a single pass through the document. > My point is that they shouldn't, and that the argument that that's > somehow prohibitively expensive needs some support, given > that publishing houses routinely do it the way I am suggesting > at a far lower cost than we pay for publication. > > -Ekr > > > On Wed, Apr 16, 2025 at 1:03 PM Eliot Lear <l...@lear.ch> wrote: > >> Hi, >> On 16.04.2025 20:19, Eric Rescorla wrote: >> >> Jay, >> >> Thanks for the update. I am puzzled by the following paragraph. >> >> > Working cooperatively with authors who use GitHub is a more complex >> > proposition and is still being looked at. A stumbling block is the >> > regularly requested feature for the editors to send PRs, labelled as >> > format edits or content edits or by severity or with some other label. >> > Unfortunately this just does not fit with the way that editors work, >> > which is to identify and correct issues as they are found during a >> > review pass, whether those issues are formatting or content, or low >> > severity or high severity. Switching to a process with multiple edit >> > passes, or where every edit leads to an individually labelled commit, >> > would drastically increase the editing time and the IETF LLC has made >> > it clear that this would not be acceptable. The RPC plans to put out a >> > proposal for community discussion at IETF 123 Madrid on how it might >> > support authors who work in GitHub. >> >> First, breaking up edits between copy edit and formatting is >> orthogonal to GitHub, although they serve the same basic purpose, >> which is to make it easier for authors and the community to determine >> what has changed. >> >> Second, I am surprised to hear that you think this is prohibitive, >> because to a first order this separation is what happens when you make >> the first editorial pass on the markdown and then translate it to >> XML. There are of course some minor formatting changes that get made >> in markdown, but based on my experience backporting RPC changes into >> markdown I could at least live with that separation. I agree that >> individual commits would be prohibitive, though what *would* be >> valuable would be if the aforementioned markdown changes were >> presented as a PR so they could be reviewed and updated as necessary >> using our ordinary processes. >> >> On the bigger picture, whatever the RPC's current processes, standard >> practice in book publishing is to have copy-editing occur on >> un-typeset versions of the author's manuscript (e.g., a Word file) >> followed by typesetting of the final manuscript. This roughly >> corresponds to the content/formatting split that is discussed >> here. Can you say why you believe this would be prohibitive in this >> case? >> >> I read what Jay wrote differently. He was stating that there is a >> request that people tag PRs with different qualities like priority or >> formatting and that these PRs be handled differently based on the tags, and >> THAT flow would fly in the face of how what editors do today. Am I >> misreading what was written? >> >> Eliot >> >> >> >> -Ekr >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Apr 15, 2025 at 3:53 PM Jay Daley <exec-direc...@ietf.org> wrote: >> >>> There’s a nbew blog post that readers of this list might find >>> interesting: https://www.ietf.org/blog/rpc-retreat-2025/ >>> >>> "In early April 2025, the RFC Production Center (RPC) and IETF LLC >>> senior staff met for the first RPC retreat following the contract change >>> that now has the RPC reporting directly to the IETF Executive Director. >>> This was a high-level retreat, the first of its kind for the RPC, looking >>> at community requirements and the RPC internal processes that deliver >>> those." >>> >>> Jay >>> >>> -- >>> Jay Daley >>> IETF Executive Director >>> exec-direc...@ietf.org >>> >>> _______________________________________________ >>> rfc-interest mailing list -- rfc-interest@rfc-editor.org >>> To unsubscribe send an email to rfc-interest-le...@rfc-editor.org >>> >> >> _______________________________________________ >> rfc-interest mailing list -- rfc-interest@rfc-editor.org >> To unsubscribe send an email to rfc-interest-le...@rfc-editor.org >> >>
_______________________________________________ rfc-interest mailing list -- rfc-interest@rfc-editor.org To unsubscribe send an email to rfc-interest-le...@rfc-editor.org
