On 4/10/23 08:52, Christian Huitema wrote: > > > On 4/9/2023 9:27 PM, Keith Moore wrote: >>> >>> Yes, Github does have some features that can be used to support collaboration. But it is a collaboration flow engine wrapped around a source code management system and it is really not built for what we need for our work. So while it has some advantages, you have to be using Github **in a collaborative setting** pretty much every day to remember how it all works. The notion of forking a repository so I can submit a pull request in order to comment on something is obscurantism at best. >> >> Agree. Really it's more of a coincidence that github can be made to work at all for collaboration on IETF documents, and it only works because lots of IETFers already know git and/or github, and IETF uses XML for its editable document format. But from a different point of view, both of those choices (git and XML) make it more difficult for people to participate effectively in IETF. And I still think that early in a document's life cycle, generating pull requests is a really poor way to collaborate, and not only because of the baroque user interface. PRs only work for collaborating on a technical specification when the document is already relatively mature and most of the changes needed are fairly localized. > > It is possible to use GitHub to collaborate on an XML text, but most projects that I know of do not do that. They collaborate on editing a Markdown document, and then use tools to translate Markdown in the IETF XML format. This may very well be because using XML for collaboration is hard. > > Also, many projects try to not use PRs for discussion. They use issues instead, and only nominate an editor to propose a PR once the issue is well understood. There might be a discussion on the PR itself, but the participants are supposed to try limit that to editorial comments. Of course, emphasis on try -- tools cannot enforce that. Using a Git commit as the atomic unit for a change on a formal language (e.g., C) works because there is a validation step after this that compiles the result of applying that commit to the whole source code, runs a bunch of tests, maybe applies some static analysis to that, and rejects the commit if one of these fails. The reason why I do not think that using Git for that as a good idea is that there is no such validation after applying a commit for an informal text (English in our case), and so plenty of inconsistencies can be introduced by a commit. That is also probably the case without Git, but I think that making that step simpler means that there will be even less manual checking that the whole document is still consistent. I can be wrong, but analyzing the history of modifications between I-D's, then with the RFC, then with the Errata would help find out. And that's without even talking about the fact that the "discussions" on GitHub are not AFAIK archived AFAIK by the IETF, and thus an easy way to shove a technology covered by a submarine patent in an RFC. At least email-based reviews are available forever in the IETF archives. -- Marc Petit-Huguenin Email: marc@xxxxxxxxxxxxxxxxxx Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
