Meeting minutes
Agenda
Ege: 3 main thing on the agenda, but we postpone the decision making
TD
High-level overview of the work
<Ege_> https://
Ege: schedule for TD deliverable. Before the charter date we will stop working on big feature,
… things like historical data or data mapping are considered probably as big features
… in the main call Michael McCool mentioned we need to integrate this in the schedule
… we also follow the same schedule as discovery, any opinions?
<kaz> schedule.md
<kaz> milestone calculator
Kaz: for that purpose, we can use the milestone calculator tool
Ege: thought we already once used it, but let's check it again
Ege: looking at the milestone calculator, I proposed to put the same schedule as the discovery
… we will not merge it, but gather opinions from the others
Kaz: maybe the schedule for TD deliverable section in the work item file can be updated with the expected schedule
<kaz> (Luca joins)
Ege: (Note to Luca) as there was not so many people joining in the beginning we decided not to make big decisions in this call
Versioning Discussion
<kaz> PR 1969 - WIP: Concrete Versioning Proposal
<kaz> rendered VERSIONING.md
Ege: we will talk about the requirements for the versioning and not the proposal itself
… the requirements we have are: supporting all users of wot resources who are early adopters and REC publication users
… we want to provide concrete guidelines
… any questions/feedback?
… other small points such as what we think of post REC users, the changes should be communicated to early adopters
… in all cases we need to serve all resources at all the time
… post REC is guranteed from W3C
Kaz: consolidating the proposal like this is good, but we should clarify which part is fixed and which part is vague and need further clarification
Ege: good point
Ege: for the requirements these are the things we should agree on, maybe not today
Ege: from other spec users do you have any requirements for TD resources?
Daniel: the json schema is the one referred to, any changes to the json-schema should change the version, and that is what we are going to use for the scripting API
… in the past when some changes were done to the json-schema we changed the date, but maybe there are better ways to do that
Ege: you mean each change in the resources should bump versioning
Daniel: ideally
Luca: I think you managed to capture all possible requirements, mainly the part that is not here but is an implementation detail, making sure we can signal that some of the resources might be , if the early adopters refer to a pre-release they have something that has changed
… we can decide if we want to also embed the versioning inside the single resources
… if we want to setup or promote that we are going to make a nice changelog with commercial tools
… precise changelog in pre-release or early adopter cope with us or work with us
Ege: we have enough early adopters
Ege: when we talk about version it should be reflected in the URL as well as the resource
Ege: is anyone interested in participating in the versioning besides Luca, Mahda and Ege?
Daniel: it should be worth if from the scripting API side if either Cristiano or me should joing
… I will talk with Cristiano and let you know
Ege: In the main call we agreed that on 28th March we agree on the solution
… any opinions on this?
(none)
Toolchain Discussion
<kaz> PR 1975 - Toolchain requirements
<kaz> rendered requirements.md
Ege: toolchain requirements
Ege: when we are talking about the toolchain its not only about TD but others like Bindings
… consider a person who is an expert in the protocol but not an expert in our toolchain, we should reduce the learning curve for them
… rely on well-known tools and should be easy to debug
… since it is unlikely that one tool will fix our problems we need to chain them meaningfully
… also not to have multiple languages combined in one file
Ege: any comments?
Kaz: consolidating requirements is good as usual, but the overall requirement as a whole is also good, we should think about the expected output and existing input in general, and clarify which resource is generated by each module for the next step
Ege: right. depending on the tooling we chose we may need to do changes
… the goal is to change a small number of files while generating as many resources as possible
… the compromise is that we should at least reduce the cross checking between the files
Ege: since this is still requirements, I will ask comments from everyone here asynchronously
… we will probably have a version of the spec that is not perfect and overtime improve
Management
<kaz> PR 1977 - Project Management Improvements
Ege: In the main call we mentioned that this topic will be discussed today and will be applied to other task forces
Ege: has everyone seen this lifecycle?
… it's all about categorization and moving things in the correct place
… if there is a use case coming from the use case TF we can work on it
… of course we can have our own editorial issues
… we have to agree on prioritization, we talked with Michael Koster about this yesterday and noticed this aspect is not taken into account
… ultimately we can see the issues concrectly
… I also provided some examples
… also everything from the meeting I put them in archive so it can be read through
Kaz: thank you for creating this. minor comment, each description text should also have a number
Ege: the numbers are in the brackets, but I can add the step numbers at the beginning of each sentence.
Koster: prioritization is how things are selected to go from one stage to another
… it is really how we select the items
Koster: dependency or no one to work on it
Ege: I hope this should never happen, I hope we can either work on it ourselves or use the help from related groups like canonicalization...
Kaz: we should probably clarify what we mean by prioritization as next step, e.g., from the viewpoint of feature necessity or timing of release.
Ege: just to summarize as quick as possible, given two refined issues which one should be done first
… I have seen people doing metrics for this, doing a table with metrics like time, technicality, and so on
<kaz> [adjourned]