On Wed, Apr 16, 2025 at 12:21 PM Ted Lemon <mel...@fugue.com> wrote:
> 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. > Indeed. What I do is to generate two text files and then diff them and walk through each diff, adjusting the markdown or the XML as appropriate. I don't otherwise look at the XML beyond issues (see below). > 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. > With the right tooling, this can be automated as well, I think. When I did RFC 9570-to-be, I wrote a script to pull all of the issues out of the XML and make GitHub issues out of them (See: https://github.com/mlswg/mls-architecture/issues?q=is%3Aissue%20label%3Arfced ). I agree with you we would need to find the right workflow. Just spitballing here... - Each change should be its own commit. Commits are tagged by type [copy-edit, formatting, ...]. - RPC questions become GitHub issues, either created directly or by the kind of post-processing I mentioned above. - After the edit phase is complete, we have tooling to sort the changes by type so that all the copy-edit stuff comes first, etc. Then we make different stacked PRs for each type. This will obviously require some manual conflict resolution but I don't think too much. As I said, just spitballing, so this might or might not work, but I don't think we should just reject any improvement along these lines as too expensive. -Ekr 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> 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
