Re: [Gendispatch] Diversity and Inclusiveness in the IETF

[Martin Thomson <[e-mail]>]

On Fri, Feb 26, 2021, at 22:56, Vittorio Bertola wrote:
> My experience is the exact opposite - there were a number of times in 
> which I wanted to propose text for a document, but then I was pointed 
> at Github, and I am not at ease with it and did not have a lot of time 
> for it. So I gave up or, 

So anyone who asked you to submit an issue or write a pull request should be aware that sometimes they too need to make some effort.

As a request, asking someone to contribute on GitHub is fine. It isn't mandatory though. If you are able to, or you plan to contribute often, taking the effort makes it a lot harder for editors to take your input, track it, and integrate changes. However, if you don't, then it is best for all involved if the editors do the work of opening issues and writing pull requests (if that is how they manage the document). We did that for the IESG with QUIC, and for those who were unfamiliar with the process.

The goal should be always to take good input when it is offered. However, it always pays to make your input easier to act on. Clear, actionable input is more likely to result in actions, human nature being what it is. It is meeting in the middle. Editors are volunteering their effort too.

What we have found is that the discussion is sometimes more work to manage, for both editors and those involved, particularly when it comes to negotiating specific text. But generally the results are far superior.

To take an example, there was a discussion about the operational implications of path MTU discovery in QUIC. The initial issue was not especially clear to everyone involved, and the proposed text was not perfect either, but the resulting discussion clarified everything and the final text is crisp, precise, broadly acceptable, and - from my perspective - excellent. I have seen that work on a mailing list before and frankly, it is not so different in the end. Both methods can produce these good outcomes. I find the mailing list version quite a bit less efficient, that is all.

What really differs is that on the mailing list, you won't get that sort of engagement on every change. With QUIC, we had that level of engagement on every sentence that was added. So yeah, it cost more, in several ways. One way being that it was not suitable for casual engagement, something that I think needs work, as not every document needs that same level of intensity.

I am happy with the results and would recommend the process.

Understanding its limitations is important though.  We are still learning as a community, even if some of us are very familiar with it.  Collectively knowing what is possible, what works, what to avoid, and when, will take some time. I can't, however, accept any of the arguments presented so far that imply that this is bad enough to stop. And the suggestion that this is, or even might be, inherently exclusionary is one I just don't see. Our goal has always been to offer more ways to engage. At worst, I would suggest that your experiences are part of us all learning together.