> The discussion moved into "I want to use my tools and not yours". Not really. You began this particular subthread when you attempted to defend the "let all the flowers bloom" approach by saying: for cross area reviews all you need are IETF drafts. I doubt that reviewers are interested in digging through the Github issues, PRs, and mailing list discussions. Speaking as 30 year IETF participant, including four years as an apps AD and many stints as a WG chair, this is not now and has never been my experience. I could not even begin count the number of times I've had to review mailing list discussions as part of reviewing a draft. This was especially true when performing cross-area reviews as an AD, where let's just say that asking questions about contentious issues without being intimately familiar with the background was not a recipe for success. And in the past month or so, while participating in DMARC and EMAILCORE, I've been compelled to dig into the archives of various lists at least a dozen times, maybe more. So maybe the drafts are enough in your world. But they most definitely are not in mine. Of course this becomes a serious problem if the material I need to review ends up scattered across multiple tools. This isn't a matter of "my tool is better than yours". As it happens I use git on a daily basis and modulo some issues with terminology I quite like it. That said, to the extent I have problems with git, it's because I also regularly use Mercurial - which as it happens I dislike - and constantly transitioning between the two can be ... jarring. And this leads me to the closely related issue: Context switching. Even if a single tool is used for developing a given draft, having to constantly switch between a bunch of different tools for different drats or WGs or whatever is also a major PITA. > There is no middle ground. You want to have everyone use email so you can > scan through discussions more easily. Others, who have been working on > implementations are familiar with Git, and they seem to feel that they are > most efficient using those tools. Nope. I don't especially care what tools are used. What I want is consistency, because anything else brings with it very substantial costs, costs you are dismissing in a cavalier way that borders on offensive. And like it or not, we have 35+ years of discussions of drafts captured in mailing list archives that are not going anywhere. This is a real cost that cannot be poo-poo'ed away with handwaving arguments about use of obsolete technology. The benefits of any new approach have to be weighed against these costs. > Regarding "those who actually do the bulk of the work". There are lots of > steps to get to widespread deployment of technology. Writing the spec is only a > small part of the job. Producing implementations of the specs, and deploying > them is a big part of it. Sometimes you can observe that people write > specifications and then they run away because they believe the work is done. It > is often more exciting to work on the latest thingy rather than doing the other > 20% of the work that take 80% of the time. > Those folks in the community who do also the last 20% should get credit and > if we can make their life easier I believe we will get not only more done but > we will also be more successful as an organization. Hmm. You started by saying that in order to review a draft all you need is the draft itself. But apparently to *implement* a draft it's useful if not essential for the discusions of that draft to be stored in an "implementor friendly" way. I think you just contradicted yourself. In any case, and now speaking as someone who has often gone back to my hotel room after a session and implemented the latest changes in the draft, I find early implementation and review both require access to the discussion of issues. And not to put too fine a point on it, I'd be far less inclined to implement an in-progess draft if the issue discussions are somwwhere other than on the mailing list. Not because the list is the technology I prefer, but because it's technology I have to use for other drafts. Actually make that, "Pigs will fly first". Ned
