[procon] Re: [Gendispatch] Issue tracking [was Re: Derivative Works: draft-sayre-gendispatch-derivative-01]

[Stephen Farrell <[e-mail]>]

Hiya,

On 16/07/2026 03:23, Brian E Carpenter wrote:
> On 16-Jul-26 10:42, Eric Rescorla wrote:
>> Thanks, Brian. Appreciate you changing the subject.
>> 
>> FWIW, a number of IETF WGs do do issue tracking in GitHub. For 
>> instance, QUIC, TLS (at least TLS, DTLS, and ECH specs), AIPREF,
>> etc.
> 
> Yes, and individual drafts now often have this too (with or without 
> automatic copies to the WG list). I think this is in general a good 
> thing, and I'm not sure we need formal rules about it - but it does 
> provide common knowledge about detailed discussions that might
> otherwise remain private, and that can only be a good thing.

I'd say s/can only/is often/ - it is entirely easy for people
who aren't active at the same time as others to miss out on GH
discussions that are more synchronous than email.

Often, we get that right, but not always. And of course, not
everyone has a GH a/c or is following a discussion on there.

GH notifications are also (for me anyway) non-optimal as they
aren't foldered the same way as IETF email and include lots of
irrelevant (for IETF purposes) notifications, such as CI fails.

Basically, YMMV, but GH issue tracking isn't bad, it's just
not a panacea, but all the above is I guess well-known.

Cheers,
S.

> 
> Brian
> 
>> 
>> -Ekr
>> 
>> 
>> 
>> On Wed, Jul 15, 2026 at 3:03 PM Brian E Carpenter 
>> <[e-mail] <mailto:[e-mail]>>
>> wrote:
>> 
>> I'll simply observe that this whole subthread is irrelevant to
>> the draft in the Subject header. Whether issue tracking should be
>> a formal part of the IETF standards process is an interesting
>> question but IMHO it needs its own draft.
>> 
>> Regards/Ngā mihi Brian Carpenter On 16-Jul-26 06:40, Michael
>> Richardson wrote:
>>> 
>>> Jeffrey Haas <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> I am guessing the primary reason we don't track
>> concerns in any
>>>>> systematic way is because WG Chairs find this too much
>> work.
>>> 
>>>> This will probably fall to the culture of individual
>> working groups.
>>> 
>>> Yes.  It is the job to make sure that issues are tracked.
>>> 
>>> Most of the time, that means some combination of bribes and
>> guilt-trips of
>>> the authors to get the work done.
>>> 
>>> But, sometimes that also means taking the review email, and
>> splitting it up
>>> into issues/subissues (I'm still on the fence as to whether
>> github's "new"
>>> subissue system is useful), and then proding the *WG* to deal
>> with it.
>>> Solving the problems is not the sole responsability of the
>> authors.
>>> As *editors*, in some ways, they should only do what the WG
>> tells them, but
>>> most editors are also significant contributors....
>>> 
>>>> For my part, when we hit last call, I tend to review the
>> list archives
>>>> to attempt to assess how discussion was addressed.  I
>> believe this is
>>>> common practice among many chairs.
>>> 
>>> It's an explicit shepherd activity. Which often falls to the
>>> chairs.
>>> 
>>> While I was tolerant of github issues (v6 being one) in years
>> past, the
>>> recent disasters there have now convinced me that we have to
>> control our own
>>> stuff here.  The OpenPGP WG has used gitlab for along time.
>>> 
>>> *git* itself is very marxist, in that all repositories are
>> equal, so
>>> that part of the backup is immediately useful... but the issue
>> tracking
>>> stuff, and the magic "close #xxx" is not, since the XXX is
>> essentially a
>>> github-local artifact.
>>> 
>>> -- ]               Never tell me the odds!                 |
>>> ipv6
>> mesh networks [
>>> ]   Michael Richardson, Sandelman Software Works        |
>> network architect  [
>>> ] [e-mail] <mailto:[e-mail]> http://
>> www.sandelman.ca/ <http://www.sandelman.ca/>        |   ruby on
>> rails [
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________ procon mailing
>>> list -- [e-mail] <mailto:[e-mail]> To unsubscribe
>>> send an email to [e-mail]
>> <mailto:[e-mail]> --     Gendispatch mailing list --
>> [e-mail] <mailto:[e-mail]> To unsubscribe
>> send an email to [e-mail] <mailto:gendispatch-
>> [e-mail]>
>> 
> _______________________________________________ procon mailing list
> -- [e-mail] To unsubscribe send an email to procon-
> [e-mail]