OpenOOH Venue Taxonomy 1.1 Release Planning Agenda

[jayshao]

Proposed Agenda for 2/23 Release Review

1. Welcome [10m]

2. Review categorized issues against 1.0 (upvoted/consensus, contentious, unclear) [5m]

3. Discuss/Confirm easy inclusion/rejection issues for inclusion in 1.1 [5m]

4. Discuss/Confirm major issues for 1.1 [30m]

   a. Add: Handling of unrecognized categories (e.g. forwards compatibility) #43 Forwards Compatibility
   b. Protocol: Deprecate "string value" fields for future versions of the spec #54 Deprecate “string value” fields
   c. Clarify BidRequest limiting requests to a single venue category (parent, child, or grandchild) #37 Limiting to a single Venue Category

5. Determine target timeline/date for 1.1 release, and review process. Strawman below [10m]

   a. Incorporate issues into a 1.1 DRAFT1 for community review by 5 Mar 21
   b. Open review and comment from 8 Mar 21 -> 19 Mar 21
   c. (near-final) 1.1 DRAFT2 for community review by 22 Mar 21
   d. 1.1 Release 31 Mar 21
   e. Drive adoption with current and new partners

[jayshao]

Notes from meeting on 2/23:

Reviewed current list of issues tagged for 1.1 - and potential rejections. Tagging conventions:

• needs help = requires more discussion
• invalid = candidate for rejection

4. Discussion Points

#54 Deprecate "string value" fields

• some implementors are using string fields as part of their implementation
• we don't want to suddenly cutoff something when it's being used
• what happens when labels change? renames / localization?
• should OpenRTB be machine-to-machine
• could announce, but target removal towards the end of the year? (1.3? 1.4?)
• alternative: change the semantics of the spec to pass human-readable, but not guarantee machine parse-ability and compatibility

Proposal: Deprecate string values with removal in 1.4 (+8. -1)

#43 Forwards Compatibility

• lowest-friction convention seems to be "ignore categories you don't understand" but does that cause blocking challenges?
• blocking can be handled against other attributes (e.g. media-owner)
• DSP could take on responsibility to update their taxonomy based on their risk tolerance
• allow list could be recommended as an approach instead of relying on blocking categories
• so far most feedback/comments have been relatively minor
• we could specify how to handle unknown categories - block them into "other" perhaps?
• do we want to incorporate semantic versioning? what is the threshold of materiality of a "major" change that would prompt a 2.0?

Proposal: DSPs should ignore unknown (presumably more recent) categories (+7,-0)

#37 Limiting to a single Venue Category

• counter-proposal to discard hierarchy, and allow multiple, flat tags
• concerns about fragmenting based on different interpretations, or how to interpret
• there may be some benefits to constraining the number of categories - and forcing smaller sub-divisions
• adjacent POI or other metadata could represent multiple categories if we force a single assignment?
• would that be the same spec? or would it be orthogonal?
• one merit of tagging is allowing cross-cutting categories
• how complicated should the taxonomy be? When should we rely on other targeting (e.g. PMPs)

Proposal: Clarify spec that the expectation is a given request is only classified against 1 venue (+7, -1)

5. Next Steps (to get to 1.1)

Proposed rule of the road:

1. Use PRs to merge changes into a 1.1 draft (at least +1 approval from someone other than submitter)
2. Call a vote to approve 1.1-DRAFT1 (Majority over Slack within 48h)
3. Call a vote to approve 1.1-DRAFT2 (Majority over Slack within 48h)

Followup call to be scheduled around DRAFT1

[jayshao]

This happened - marking as answered