Clarify Adoption Policy

[mmccool]

We need to clarify the policy about when the WG will or should adopt a requirement identified in a use case. Currently the use cases and requirements document is an IG activity but also includes contributions from the CG and non-members. However, addressing a particular requirement in the WG needs some additional considerations, such as identifying a set of WG members who can work on it. Also, something may be a requirement but may not need a normative standard to address, possibly.

I am creating this issue so we have a place to address what our policy should be to adopt a particular topic in the WG charter for standardization work.

[mmccool]

Some thoughts for discussion:

• Prioritization. Which use cases are most important and why? What can wait and what needs to be done immediately?
• Prerequisites. Do we have to accomplish some requirements before others?
• Availability. Who is available to work on various topics and what is their expertise?
• Adoption. What work would best drive takeup of the standards in the short term?
• Experience. We only want to work on standardizing something in the WG if a solution is well-understood, at least in theory. Otherwise solutions should be incubated in the IG.
• Need. Is a standard NEEDED to address the requirement, or can it be solved in other ways?
• Stakeholders. Who is impacted or benefited? Are all stakeholders "available" to do technical work, or do some need to be "represented" by others?

[mmccool]

Discussion (Meeting Jan 16, 2023)

• Need to be careful about who provided use cases; need people willing to do the work; also, how do we weight use cases from non-W3C/WoT members? (new points above: Stakeholders)
• Use Architecture TF to help decide process and feedback on use cases?
• Use cases we have currently are not technical enough to define requirements in many cases; sometimes very generic. Lots of use cases, but not enough detail. Sometimes it is hard also to contact the original contributors (e.g. to get more detail)
• What about features that come from issues? Feature requests? Iterative vs. waterfall?
• Needs to be a requirements document for each specification. What is in scope, what is out of scope. High-level use cases are not detailed enough at the specification level.
• Regarding stakeholders, we have to learn from people who are not members of WoT, have an open door to gather outside input. Good also to have non-technical input, including users and business people, and people who are not over-familiar (necessarily) with the current spec. But a spec-writer needs to sit with them and extract requirements (and use case details).
• Previous approach was to have requirements doc for features, not specs.
• Need to clarify policy and process/workflow, and how to generate requirements as (a) concrete document(s).
• What is the role of the Web and the W3C in the context of IoT?
• We need to consider common patterns and trends, e.g. hubs, edge computing, AI, etc.
• How to answer simple business questions, eg. integration into existing processes? How to maximize adoption (e.g. which of the new items on our plate would maximize adoption in the short term?)
• WoT members/editors need to work with rest of community
• However, if members DO work on detailed requirements for use cases, ends up looking like consulting

[sebastiankb]

from today's charter discussion, there is a resolution:

"The WoT WG will prioritize work that leads to commercial adoption of WoT standards, including liaisons with other SDOs and meeting the stated requirements of potential commercial".

We can close this issue