Meeting minutes
Minutes Review
<kaz> Nov-20
Cristiano: Minutes look fine to me, any objections to approving them?
No objections, minutes are approved
Schedule
Cristiano: As you might know, we adjusted the schedule to only have biweekly calls
… we will have to reevaluate in the next year
… so next week, there will be no call
… call in two weeks has a conflict with a meetup of the Nordic Smart Cities CG
… therefore, we could cancel next week's call instead
… having a last call on the 11th would be nice, but we could also cancel the last call of this year
Kaz: Please remember you should join the Nordic Smart Cities CG itself if you want to join the CG's meeting :)
<kaz> Home page of the Nordic Chapter Smart City / Web of Things CG
Cristiano: Will do
… (adjusts the Wiki page regarding the cancelled meeting on the 18th)
… I would then like to have the last call next week
… after this call I will send an email with the updated schedule, announcing that a scripting call on the 11th will take place
Zoltan: Question regarding the Nordic Smart Cities CG: Is it the same as WoT?
Kaz: No, that is a different CG organized by the W3C Nordic Chapter working on promoting W3C standards. Also liasons with smart-city related SDOs. Is independet from WoT CG
… their discussion is very interesting, but don't need to join the call every time.
PRs
PR 489
<kaz> PR 489 - Better types for Scripting API
Cristiano: Issue still remains, need some more research
… apparently, the others in the group did not have the time to check as well
Daniel: With the updated discovery API and a better typing, some of the issues might be resolved
Cristiano: will play around during the Christmas break
PR 524
<kaz> PR 524 - Update text and examples regarding the fetching of TDs
Cristiano: PR by Jan, aligns the text and examples with the new discovery API
Jan: removed mentions of fetch in the examples and text, and replaced it with our own requestThingDescription method
… validation might need some more discussion
Zoltan: I am against removing fetch from the spec, since fetch was just a convenience method and you cannot pass all the parameters to requestThingDescription
Daniel: We can add a note, in general we should encourage people to use requestThingDescription, as we are also doing it in node-wot
Jan: fetch is still mentioned, however, so that could still cover it
Zoltan: Should add an explanation for when to use fetch and when to use requestThingDescription
… we removed fetchTD back in the day since it did not cover all the use-cases
… so there is more explanation required
Cristiano: (adds a comment to the PR)
<kaz> Cristiano's comment
PR 525
<kaz> PR 525 - Use simple single and double quotes in code examples
Cristiano: simple PR, just corrects the use of quotes in the examples
… any objections to merging?
No objections, PR is merged
Issues
Cristiano: This topic is related to the taskforce timeline
… we should organize and relabel the issues to align them with our plans
… we have 66 issues
<kaz> remaining 66 issues
Cristiano: we can split the issues among us
… to check whether they make sense for the next iterations
… need to define categories first
… we have some labels already, first step could be to apply them consistently
… I wonder if we should introduce new labels for the next iteration
… afterward, we can work on aligning with TD and Discovery, and eventually define some use-cases
Daniel: We have the "for next iteration" label
… maybe we can pick out the issues from the 66 that are the most pressing for us
… now sure if we need new categories
Cristiano: For sure we can use the "for next iteration", however, it was kind of a "deferred" label. We might need to have a new label
… we can use the "propose closing" label to mark issues that should be closed
… could define a label called "next-up"
Kaz: What do you mean by that?
Cristiano: Label that is indicating that an issue should be worked on during the next year
Kaz: Could use a process similar to the one used in the TD taskforce, separating into "refactoring" and "new feature"
… should skim quickly over all the issues to determine if they are really needed from a developer's viewpoint
… should evaluate if they are really needed
Cristiano: Totally agree. I am trying to categorize, however, which issues we should review in the near future and which ones we should come back to later
Daniel: We could use something like priorities
… something like "Priority 1", "Priority 2"
Cristiano: How about something like "Priority: high", "Priority: low"?
… should we mention the year in the description so that we know that it is for the upcoming year
Zoltan: We could reuse "Next iteration", but priorities would also work
… I agree with Kaz, though, that we should be consistent across Task Forces, so we could reuse the TD approach
Kaz: We could look into the TD repository to see examples of labels
… but the next step before attaching labels could be simply closing obsolete issues first.
Cristiano: Relationship with TD is really important, maybe we could even add a label linking relevant issues with TD
… for all the 66 issues, it might be better to do it as a homework
<kaz> Issue 190 - Create testing plan
Cristiano: an example is issue 190 (Create testing plan), which has been stale for four years
Daniel: Adding "Propose closing" and pinging the author could make sense
Zoltan: It is an important issue raised by a Chair, however. We need more test cases
Cristiano: Will add a comment and the label "priority: low" for now, not "Propose closing"
Kaz: As you all know, testing is required only for the REC track documents
… testing is not required for the Note documents
… if we want, we can still try that
… but it is not necessary
… my personal opinion is that it is not a technical issue, but that the WoT WG should think about how to deal with testing in general
Cristiano: (updates the comment)
Zoltan: I think McCool originally might have been thinking about something different than what we are discussing now
… he rather meant generating some test cases automatically
Kaz: Having some general guidelines for testing would be useful, although it is a bit too much for us at the moment
… this is why I am proposing dealing with this on the WG level
Cristiano: (Finalizes the comment)
<kaz> Cristiano's comment
subtopic Issue 299
<kaz> Issue 299 - Chose a particular security schema for an ExposedThing
Cristiano: This might be useful in the next iteration
… with the current API it is a bit difficult to direct the underlying platform which security scheme to use
… comes from experimentation with node-wot and a real use-case
… tend to add a high priority label
Issue 303
Cristiano: Issue opened by Zoltan
… but as we are out of time, everybody should go through the issues and evaluate them
<kaz> [adjourned]