On 28-Feb-21 08:01, John Levine wrote: > In article <CAMm+LwhOqy2MCmAY5eO2OcpkM99UOS7A5hJaj+thA3SuO+g8FA@xxxxxxxxxxxxxx> you write: >> Previous attempts to get a discussion going on what tool we would want... >> haven't exactly been successful. They turn into a github vs mailing list >> editor war when my interest is quite different. > > I agree that neither mailing lists nor github are ideal for the way the IETF works > today but I would be very unhappy if we invented yet another bespoke locally maintained > bunch of software. > > We're strange but it's hard to imagine that we're so strange that there isn't an > existing package somewhere that will do the job either as is or with minor > customization. You'll never, ever get everybody to agree on this topic, because people come at it with different backgrounds, habits and skill sets. So it's futile to expect that everybody will be happy. I really don't think we'll get anything significantly better than what we have now as the reference/archival/canonical format, which is xml2rfcv3. Why? Because it expresses what our document series needs in the way of metadata. That's all. It's ugly to look at, but we don't expect typical readers to look at it. It's ugly to edit, which many of us don't actually care about (I'm perfectly happy to edit it with XML Copy Editor, as it happens), but we have kramdown to avoid that ugliness. That's quite separate from how we manage collaborative editing. GitHub is one way, and it suits some people. Quite a few of us used Subversion in the past; we did in fact use Subversion and trac as the basis for the ION documents experiment. If you want to see what it looked like: https://web.archive.org/web/20080216034049/http://www.ietf.org/IESG/content/ions.html IMHO, mixing Subversion and trac was complicated and confusing. I'm willing to believe that GitHub is better. I've used "track changes" for collaborative development of .doc and .docx documents, and found it confusing and error-prone when more than say, two, authors were involved. I am quite confident you will never get broad consensus on the best approach to collaborative editing. As long as we stick to BCP25, this doesn't matter, because editing is only a tool and not a method of determining consensus. Allowing individual authoring teams and WGs to choose the method of collaborative editing that suits them best seems good to me. Brian
