[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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> >> _______________________________________________ >> rfc-interest mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > > _______________________________________________ > rfc-interest mailing list -- [email protected] > To unsubscribe send an email to [email protected] > >
_______________________________________________ rfc-interest mailing list -- [email protected] To unsubscribe send an email to [email protected]
