EKR has raised some really good questions here. Having just been through a very painful pair of AUTH48 reviews, I can say that not doing the changes as pull requests in github caused me a HUGE amount of work when I needed to back out some changes that were made. Not only was it a lot of work, but it was really overwhelming to be faced with the need to reverse engineer what had been done by the RPC during the edit process and back-port it to github.
If the cost to the authors of the current flow is not taken into account, I can see where it might seem expensive to switch to a github flow, but if you consider _everyone's_ workload and not just the RPC workload, I think it's pretty clear that the cost of doing the work in github via pull requests is lower. Also, it's better for the process. Because the changes from the RPC were presented as a single hunk, it was impractical to do working group review of the changes, and although we did our best and I think did pretty well, that was quite expensive and not at all satisfactory. We would do a much better job of serving the IETF consensus process if RPC edits were done using the same workflow that we used in the working group. I can see how doing a multi-pass edit might not be workable, but I am _highly_ skeptical that doing individual pull requests is not workable. Given that right now the RPC simply adds comments to the XML file and makes individual changes, the additional work involved in doing these as new issues (when the authors are requested to consider something) or as pull requests (when the editor wants to make a particular change) is quite straightforward. I suspect that the issue is that the right workflow hasn't been found yet. E.g., each individual edit could be a separate commit, and pull requests could include multiple commits. This is easier to do because the pull requests don't have to be mutually independent, but still creates a semantic separation between different edits that can help the authors during AUTH48 review and can help the working group if the working group needs to be consulted on the results of the AUTH48 review. Thanks for this report. I hope we can work forward to a better process as a result of the retreat and this conversation. > On 16 Apr 2025, at 12:19, Eric Rescorla <e...@rtfm.com> 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? > > -Ekr > > > > > > > > > > > > On Tue, Apr 15, 2025 at 3:53 PM Jay Daley <exec-direc...@ietf.org > <mailto: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 <mailto:exec-direc...@ietf.org> >> >> _______________________________________________ >> rfc-interest mailing list -- rfc-interest@rfc-editor.org >> <mailto:rfc-interest@rfc-editor.org> >> To unsubscribe send an email to rfc-interest-le...@rfc-editor.org >> <mailto: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
