Meeting minutes
Minutes Review
<kaz> Dec-6
McCool: we looked at them in the chairs call
McCool: there is no issues at them. Any objections to publish?
McCool: minutes are approved
Quick updates
McCool: there is a nordic smart city cg meeting next monday
… I am not sure about joining
Kaz: I have emailed them about a proposal on how to collaborate
Meeting Schedule
<kaz> Cancellations and schedule updates
McCool: next week is the last main call
… no scripting, discovery and security on monday
Kaz: regarding the "Cancellations section" of the main wiki, each TF should clarify their schedule
McCool: let's update this since we are here
Daniel: Jan 8th is holiday in Japan, probably cancel scripting call?
Kaz: Right. Thats why I'm suggesting each TF moderator should think about the schedule
Group Schedule
McCool: I will retire the 1.1 items from the schedule.md
Rescheduled Meetings
TD TF
McCool: the TD call slots are fixed now
Ege: wednesdays start with TD topics, thursdays start with binding
Use Case TF
McCool: we need to have use case calls
… also to get input from contributors and get additional work
McCool: we cannot go through all the use cases in the call
McCool: security tf is doing some prework
McCool: we need to find new tf lead for use cases. We should open the floor for leads
McCool: we will start a doodle for the slot
McCool: the slots presented are filtered based on my and Kaz's availability
Ege: shouldn't we pick a tf lead first?
McCool: me and kaz should be present anyways
McCool: we can ask for tf leads with a deadline
Kaz: We should ask for volunteers for all missing TF leads
Kaz: probably it is time for us to have an official call for nomination
McCool: I also think that the tf lead should be also an editor
David: I would be available for use cases calls about the retail
McCool: I will send a call-for-nomination email about the TF leads
Ege: Should we start the work for all of them at the same time?
McCool: I think we can postpone arch and profile and focus on use cases. we need to recruit people
Ege: I agree that we should focus on use cases.
McCool: we can do that
Kaz: I agree on concentrating on use cases first
McCool: We should do it for discovery and security as well since they are urgent
Kaz: We can start with the Use Cases TF and the Security TF for the Call-for-nomination then
Project Management
<McCool> w3c/
Ege: we have an initial PR with a draft containing opinions
… we can merge that and discuss this more
Kaz: We need more time on this discussion, so probably not for today. So far, TD-TF has been working on how to use GitHub's "Project" capability to manage progress but we need to understand our requirements as the whole WoT WG
… if the whole group is OK to ask the TD TF to see how to use the GitHub's "Project" capability, we can ask the TD TF to draft a proposal about possible policy
McCool: sometime in january we need to have a special call about this
Publications
McCool: everything is done for publications
Resources
McCool: we have an html placeholder for the discovery
w3c/
McCool: we will ask for reviews from the group
McCool: we should be careful about versioning
Kaz: we need to maintain the resources for 1.1 during the new charter as well. regarding the remaining problems on Discovery and TD, we should have two issues on wot-resources, one pointing the issue on wot-discovery and another pointing the issue on wot-thing-description.
Ege: so the resources can be updated outside of the REC process?
McCool: yes, it is not prohibited by W3C
Kaz: breaking changes should be added to the new version. also we need to clarify the policy on how to maintain and update wot-resources.
McCool: any changes must be versioned
McCool: I will archive the meeting agendas for next year
Meetups
Grundfos
Ege: there was a nice talk from Grundfos with usage of our ontologies in an upcoming ISO standard
… he mentioned the importance of our plugfests
McCool: we need to think about the right way to do that
Kaz: As I mentioned, we need to think about this whole process
… maybe we need liaison tf
McCool: there are different cases, i.e. a company using our specs, an sdo
McCool: we should add review process for ontologies
Kaz: we are getting input from outside of ig/wg, we need to discuss how to incorporate such input
… this is important for the IG charter discussion, so would suggest we create several GitHub Issues on wot-charter-drafts for the WoT IG discussion
JP CG
McCool: any updates?
Kaz: there is something happening related to the smart cities ig
Liaison
McCool: do we know the ISO group that the Grundfos work is happening at?
Ege: I need to check, there are different iso liaisons already
Kaz: is he a liaison contact?
Ege: I do not know, let's discuss seaprarey
Kaz: In that case, let's have some more discussion offline. I can explain what is needed for "W3C Liaison" to you and the Chairs again.
TF Reports
Marketing
<kaz> MarComm Team's announcement (Member-only)
Kaz: as above, W3C MarComm Team sent out an announcement saying W3C as a whole is switching to Mastodon
… but we ourselves can make our own decision
… I personally would suggest we also use Mastodon only because double posting would be time-consuming
<Ege> @wot@w3c.social
<McCool> proposal: Create a Mastodon WoT channel called @wot@w3c.social
RESOLUTION: Create a Mastodon WoT channel called @wot@w3c.social (tentative resolution - effective in 5 working days)
Kaz: just to make sure, if the name (@wot@w3c.social) is not approved by the MarComm Team, please check with them first
<kaz> [ break ]
IG Charter
Kaz: given the small participation and lacking two of the three co-Chairs
… we should clarify what to do for today
McCool: don't think we can merge PRs today
… can still look into the proposed text, though
PR 137
PR 137 - Update text for Plugfest and Testing
Ege: also thinking about plugfest and testing through the CG discussion
… think testing for each spec should be done by each TF who is in charge of that spec
McCool: TF is in charge of the Implementation Report
Ege: CG participants also could submit test input
Kaz: what do you mean?
McCool: test input covers test cases and test results
Kaz: what do you mean by test cases?
… example data for each assertion?
… maybe we don't need to clarify those terms within the IG Charter itself, and rather we should remove the details
… but we do need to clearly define what to be done by whom separately
McCool: (puts comments about that)
… charter itself could be "vague"
… "test input" could include "test cases" (example data) and "test results" (CSV files)
Cristiano: partly defining the policy for WG?
McCool: WG is in charge of the Implementation Reports
… we need to clarify the policy for IG as well
Kaz: in any case, we need to clarify the roles of the groups
… who to do which part of testing
<MIzushima> +1 for kaz
Ege: we need to come back the discussion on "which group to do what" question
… have been working on the question for a while
PR 134 - Relationship among WoT groups
McCool: wondering if using drawio would be good for standardization work
… (but goes through the diagrams anyway :)
Ege: so far putting all the diagrams into one, though
McCool: don't think (only) the IG generates the requirements by themselves
… should clarify who to generate requirements
… myself think each TF to do that
Kaz: how to describe the bigger mechanism, who to make contributions from outside the IG, would be the key question here
McCool: right
… maybe the next diagram on the right, (Use Cases), trying to describe that
Cristiano: great to have this kind of diagram itself
… wondering if it would make sense to describe the mechanism to get input form outside
McCool: need general policy
… e.g., have to join the IG to make contribution for the Use Cases and Requirements Note
Cristiano: what if outsiders like CG participants give input?
McCool: all the CGs make the same commitment for CLA. right?
Kaz: yes
… the WoT IG is in charge of the UC/Req Note
… the Note is not normative
… so the IG can accept proposals from outside including CGs and external SDOs equally
Ege: (continues to explain the other diagrams)
McCool: "Plugfest" has several purposes
… evangelism, testing, etc.
… specifically for interoperability testing
Kaz: diagrams may give different impressions to different people
… so I'd suggest we concentrate on the text description first
… and think about how to fix the diagram later
[adjourned]