[Mod-discuss] Re: issue tracking (was Re: Examples of dissent on mod-discuss)

[Ted Lemon <[e-mail]>]

On Sep 15, 2025, at 14:27, Lars Eggert <[e-mail]> wrote:
> we've left the scope of what this WG is supposed to work on.

I hope you are not suggesting that I took the first left turn off the race track! :)

> On Sep 15, 2025, at 12:22, Ted Lemon <[e-mail]> wrote:
> At the same time, we have participants who vehemently object to GitHub. etc. being used for issue tracking and require everythign to be in email.

> Some parts of the IETF have had success working a bit in this way (e.g., QUIC), but this approach is hence failing to get traction more widely.

I've never seen an actual issue tracker as Dan described it used publicly. Github is definitely not that. It's possible that some chairs personally track issues in the way Dan described rather than simply reviewing the discussion when the WGLC expires, but I've rarely seen anything like this show up in a consensus call.

What I mean, and I think (perhaps I am assuming to much) Dan means is a tracker where when someone says something on the mailing list, the chair or secretary looks into the issue tracker to see if what is said is on an existing topic or a new topic. If the former, this person then checks to see if the message says something new, or is just repeating old stuff. If it says something new, the comment is marked as saying something new and added to the tracker for that topic. If it's repeating something that was already said, this person responds to the message, pointing out the existing comment that seems to match what was just said and asking if they are missing something. If it's a new topic, a new topic is created in the issue tracker and the message is added as its list of comments, since obviously it can't be repeating anything if it's a new topic. And of course if something is raised that's out of scope, either the person running the issue tracker points that out, if it's clear, or a discussion is had with the ADs.

In all cases, there is direct feedback from the person doing issue tracking, so that participants know that their issue has been tracked and hopefully are satisfied and don't feel the need to repeat themselves.

The result of this process is that at the end of the last call, you have a list of issues that were raised and what was said about them. If anybody is in the habit of repeating themselves, it quickly becomes obvious and if pointing out that they have been heard doesn't stop them doing it, then appropriate moderation can be undertaken.

I think this probably is out of scope for this WG, but that's what I mean when I talk about an issue tracker. The issue tracker on github actually makes it harder to evaluate consensus, because discussion can occur there and doesn't show up on the working group mailing list. Which is why I object (not vehemently) to using github to track issues, even though I agree that it makes the job of editing the document easier.

What is nice about an issue tracker like this is that it lets people feel heard, and provides a concrete and easily followed record of what the result of their contribution was. They may not like the outcome, but they can clearly see that what they said was taken into account.