Subject: [Edm] Fwd: Implementation status tag name: please bikeshed!

From: Robert Sparks <[email-masked]>
Date: Mon, 7 Feb 2022 11:14:32 -0600

(retry with a better from address - apologies to the list moderators for 
noise)

Glad to see people aren't piling onto this particular bikeshed :)

The only things that we get by adding a tag are making it more likely 
that the descriptions of the links appear the same on group or document 
pages, but be aware that these descriptions can be edited arbitrarily, 
and to make it so that datatracker code (or code using the datatracker 
API) in the future can treat these links as semantically different from 
webpage links or github* links.

To optimize both of those things, if we create a different tag, let's 
try to make the semantics match what we're really trying to say with it 
as best we can.

Given that we want to capture not just implementations of a spec (or of 
a group's set of specs), but also testing tools and analyzers etc, I 
propose 'related_implementations' with the display name of "Related 
Implementations" (even though that's a bit long).

RjS

On 2/4/22 11:58 AM, Tommy Pauly wrote:
> At out last call, we discussed adding a single tag that WG chairs and 
> document authors could use to point to a resource for implementation 
> status/info/guidance/code or interop testing.
>
> The question is what the tag name should be! This is a bikeshed, but 
> we should decide on something before IETF 113 so we can add it for 
> people working on the hackathon and in working groups.
>
> For reference, the existing tags are: faq, github_org, github_repo, 
> github_username, gitlab_username, jabber_log, jabber_room, 
> mailing_list, mailing_list_archive, repo, slack, tracker, 
> webpage, wiki, yc_entry, yc_impact
>
> Some options to start us off:
> • implementations (display as “Implementations”)
> • impl_status (display as “Implementation Status”)
> • related_code (display as “Related Code”)
>
> Please reply with other options, or which option you prefer.
>
> You can also chime in on the GitHub issue: 
> https://github.com/intarchboard/program-edm/issues/15
>
> Best,
> Tommy

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 7 Feb 2022 20:48:11 +0000

‘related_implementations' or ‘related_code', as described below,  work for me, with a slight preference for related_code.

Cheers,
Charles

On Feb 7, 2022, at 9:14 AM, Robert Sparks <[email-masked]<mailto:[email-masked]>> wrote:

(retry with a better from address - apologies to the list moderators for noise)

The only things that we get by adding a tag are making it more likely that the descriptions of the links appear the same on group or document pages, but be aware that these descriptions can be edited arbitrarily, and to make it so that datatracker code (or code using the datatracker API) in the future can treat these links as semantically different from webpage links or github* links.

To optimize both of those things, if we create a different tag, let's try to make the semantics match what we're really trying to say with it as best we can.

Given that we want to capture not just implementations of a spec (or of a group's set of specs), but also testing tools and analyzers etc, I propose 'related_implementations' with the display name of "Related Implementations" (even though that's a bit long).

RjS

On 2/4/22 11:58 AM, Tommy Pauly wrote:
At out last call, we discussed adding a single tag that WG chairs and document authors could use to point to a resource for implementation status/info/guidance/code or interop testing.

The question is what the tag name should be! This is a bikeshed, but we should decide on something before IETF 113 so we can add it for people working on the hackathon and in working groups.

For reference, the existing tags are: faq, github_org, github_repo, github_username, gitlab_username, jabber_log, jabber_room, mailing_list, mailing_list_archive, repo, slack, tracker, webpage, wiki, yc_entry, yc_impact

You can also chime in on the GitHub issue: https://github.com/intarchboard/program-edm/issues/15

Best,
Tommy
--
Edm mailing list
[email-masked]<mailto:[email-masked]>
https://www.iab.org/mailman/listinfo/edm

---

From: Robert Sparks <[email-masked]>
Date: Mon, 7 Feb 2022 14:58:36 -0600

On 2/7/22 2:48 PM, Charles Eckel (eckelcu) wrote:
> ‘related_implementations' or ‘related_code', as described below,  work 
> for me, with a slight preference for related_code. 

I'm trying to inform future suppliers of links as to when they should 
choose the new tag vs the existing repo, github_repo, or github_org tag. 
`code` by itself is pretty sweeping.

But it's likely already poorly defined soup, so what's a little more 
confusion?

>
> Cheers,
> Charles
>
>> On Feb 7, 2022, at 9:14 AM, Robert Sparks <[email-masked]> wrote:
>>
>> that the descriptions of the links appear the same on group or 
>> document pages, but be aware that these descriptions can be edited 
>> arbitrarily, and to make it so that datatracker code (or code using 
>> the datatracker API) in the future can treat these links as 
>> semantically different from webpage links or github* links.
>>
>> try to make the semantics match what we're really trying to say with 
>> it as best we can.
>>
>> Given that we want to capture not just implementations of a spec (or 
>> of a group's set of specs), but also testing tools and analyzers etc, 
>> I propose 'related_implementations' with the display name of "Related 
>>> At out last call, we discussed adding a single tag that WG chairs 
>>> and document authors could use to point to a resource for 
>>> implementation status/info/guidance/code or interop testing.
>>>
>> [email-masked]

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 8 Feb 2022 08:23:27 +0000

Hmmm don't we need *both* related_code (assuming some open source) *and* implementations (assuming some vendors' products) ?

-éric

From: Edm <[email-masked]> on behalf of "Charles Eckel (eckelcu)" <eckelcu=[email-masked]>
Date: Monday, 7 February 2022 at 21:48
To: Robert Sparks <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Tommy Pauly <[email-masked]>
Subject: Re: [Edm] Implementation status tag name: please bikeshed!

Cheers,
Charles

Best,
Tommy

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 8 Feb 2022 19:03:52 +0000

I don’t believe so. Implementations may be open source or proprietary. Sometimes an open source implementation is driven by a single vendor, other times it is more organic and community lead.

Eric and Robert, would ‘related_software’ be a better option?

Cheers,
Charles

On Feb 8, 2022, at 12:23 AM, Eric Vyncke (evyncke) <evyncke=[email-masked]<mailto:evyncke=[email-masked]>> wrote:

-éric

From: Edm <[email-masked]<mailto:[email-masked]>> on behalf of "Charles Eckel (eckelcu)" <eckelcu=[email-masked]<mailto:eckelcu=[email-masked]>>
Date: Monday, 7 February 2022 at 21:48
To: Robert Sparks <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Tommy Pauly <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Edm] Implementation status tag name: please bikeshed!

Cheers,
Charles

Best,
Tommy

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 08 Feb 2022 11:11:16 -0800

I’d personally urge us to start with a single tag for now, and a tag that focuses on links to implementations (related implementations, etc) which may consist of links, status, tests, or code.

My concern with focusing on “code” or “software” is that this seems to bias towards linking to the specific open-source implementations, but not including other aspects of implementation status. Thus, I see “related implementations” as the broader term that would apply to both open source and vendor implementations.

Best,
Tommy

> On Feb 8, 2022, at 11:03 AM, Charles Eckel (eckelcu) <eckelcu=[email-masked]> wrote:
> 
>> On Feb 8, 2022, at 12:23 AM, Eric Vyncke (evyncke) <evyncke=[email-masked] <mailto:evyncke=[email-masked]>> wrote:
>> 
>> From: Edm <[email-masked] <mailto:[email-masked]>> on behalf of "Charles Eckel (eckelcu)" <eckelcu=[email-masked] <mailto:eckelcu=[email-masked]>>
>> To: Robert Sparks <[email-masked] <mailto:[email-masked]>>
>> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Tommy Pauly <[email-masked] <mailto:[email-masked]>>
>>> On Feb 7, 2022, at 9:14 AM, Robert Sparks <[email-masked] <mailto:[email-masked]>> wrote:
>>>  
>>>> You can also chime in on the GitHub issue: https://github.com/intarchboard/program-edm/issues/15 <https://github.com/intarchboard/program-edm/issues/15>
>>>> 
>>>> Best,
>>>> Tommy
>>> 
>>> -- 
>>> Edm mailing list
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.iab.org/mailman/listinfo/edm <https://www.iab.org/mailman/listinfo/edm>
> -- 
> Edm mailing list
> [email-masked]

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 8 Feb 2022 19:54:40 +0000

A single 'related_software' would be OK for both open source and proprietary, so I am good with 'related_software'

-éric

From: "Charles Eckel (eckelcu)" <eckelcu=[email-masked]>
Date: Tuesday, 8 February 2022 at 20:05
To: Eric Vyncke <[email-masked]>
Cc: Robert Sparks <[email-masked]>, "[email-masked]" <[email-masked]>, Tommy Pauly <[email-masked]>
Subject: Re: [Edm] Implementation status tag name: please bikeshed!

Cheers,
Charles

-éric

Cheers,
Charles

Best,
Tommy