On Sat, Aug 3, 2019, at 03:17, Keith Moore wrote:
On 8/2/19 1:14 PM, Mark Nottingham wrote:> My experience is very much the opposite. It's easy to lose a bit of feedback in a tumult of e-mail; threads don't have any formal closure unless you impose an unrealistic amount of structure onto mailing list discussions.>> In contrast, using an issues list forces you to make a deliberate decision about the fate of a particular bit of feedback; if the person raising it disagrees with the disposition of the issue, they can complain there, to the mailing list, or to the chairs directly.>> In other words - issues have explicit states ("open", "closed"), owners, and tags ("editorial", "design"). In practice that I've seen, this means that issues get more scrutiny, and there is more accountability -- not less.Keeping track of "issues" can be appropriate when a document is in afairly mature state. Before that point, however, if discussion must becouched in terms of "issues", whoever gets to define the "issues" winsthe battles.
Having used github as a chair for tracking issues, it's been very valuable to be able to tag specific items from the mailing list as issues such that authors remember to address all the comments. I've done this by taking reviews from the mailing list and extracting issues raised, e.g.:
And likewise Authors have used it themselves to track issues from the list:
Similarly, when people have nits on the text, it can be much easier to open a merge request against the source markdown document and ask the Author to review that rather than having the author need to apply the changes, particularly when it's a bunch of related changes throughout a document. E.g.
The nice thing about this workflow is that it doesn't require github specifically, any system which allows issue tracking and git pull requests would work just as well - and the key synchronisation points are still the individual drafts which are published on the IETF systems.
---
One of the biggest challenges that the IETF has is bringing in new blood, and one of the biggest advantages of Github in particular is that it has a lot of mindshare right now, so there are many people who know how to use it and allowing them to interact with in-progress IETF documents using tools they understand is a good way to bring them in.
Having the process of joining the IETF be entirely learning a custom workflow and custom tooling which only the IETF uses is a recipe for isolation, and I would much rather see the IETF embracing the tooling that the rest of the world is using rather than running everything in isolation.
Cheers,
Bron.
--
Bron Gondwana, CEO, Fastmail Pty Ltd
brong@xxxxxxxxxxxxxxxx
