Meeting minutes
Agenda
<Ege> w3c/
Ege: Twitter page is broken
… discussion may become long
Kaz: suggest we talk about that (Twitter issue) and IIWoT topic after the policy discussion
<Ege> Also https://
Scribe
McCool: 2 hours call today, so need two scribes
… Ege for the first hour and Koster for the 2nd hour
<Ege> yes
Minute Review
<kaz> Sep-20
McCool: I would like to approve, any objections?
(no objections and minutes approved)
Quick Updates
IIWoT
McCool: they only want full papers. If anyone wants to submit, please let us know to coordinate
Kaz: it would be good to understand the relationship between such events and us
McCool: wot is not trademarked, so anyone can hold such events. It is good to mention these events at least
Kaz: let's continue on the email thread
Policies
McCool: people had time to review them. I have sent an email about them as well
McCool: If there are no comments in the PR, we can quickly ask in the meeting and then merge
Asynchronous Decision Policy
Kaz: Discussion on asynchronous decision policy itself should be done synchronously
<kaz> async-decision.md
<kaz> PR 1127 - [Policy] Move async-decision.md from "proposals" to "policies"
<kaz> ek: had discussion with Koster and Kaz, and concerned if the proposer who created a Pullrequest wouldn't participate in the discussion after the Pullrequest creation
McCool: you have a comment ege
<kaz> mm: the proposer is tasked to participate in the discussion continuously
<cris_> +1
Ege: yes it would be better if people join the meeting if they start a discussion
McCool: it would be better to not have an introduction, it is a bit too verbose
Ege: I am fine to remove the introduction
McCool: I can add your comment to the file
Sebastian: there should be no overvoting, we should have consensus
McCool: we can add it here
Sebastian: so if an editor objects something, we should discuss in a meeting
<kaz> (discussion on what "consensus" means, "Editors' consensus" or "Everybody' consensus")
McCool: it is ambiguous who makes the decision
McCool: we can add to mention "task force members"
Ege: we should reflect this in the other places
Kaz: several questions on this policy. This assumes we can start with any PR without prior discussion
… we should discuss, make pr and discuss on merging
… also it says: "if there is a difficult with reaching consensus, we should have a teleconference." This is a bit dangeours
McCool: this mechanism is mostly for small/trivial things
Kaz: having less and shorter meetings is good but we should be careful with the policy
McCool: we can add something like "each PR should have an issue linked to it"
Cristiano: sometimes it is better to have a PR with examples since you need to show something concrete
McCool: I am fine as long as it is documented in github
tm: I have same opinion as Kaz
McCool: we can add to say that an issue should be created and used for consensus reaching
… but this can block progress since it may not be clear until a PR is created
Kaz: PR is good to see diff etc. but that is a tool to change the spec. We should have discussions
Kaz: in which cases do we need a PR instead of email, meeting or issue to have a discussion
Cristiano: what we are afraid of is, what if editors change the spec without consensus
… we can suggest an issue before and we can also say that we require a minimum time for the PR to be online
McCool: yeah theoritically one can create issue and then a PR and merge it in the same day
… we should add a time limit
Sebastian: we already have issues before PRs, generally
… we should be clear why we are doing this
… we are not perfect in that regard, we are quite slow
… big topics like canonicalization should be discussed in a meeting anyways
<Zakim> McCool, you wanted to react to sebastian
McCool: we should distinguish big changes. Like editors identifying such big changes
Luca: we should have a timeout, what if no one comments on the PR?
… should we agree to look at the PRs, like at least once a week?
… the main point is to make the progress smoother
McCool: editors should do that
Kaz: It sound to me that we're mixing up the spec generation timeline issue and how to propose changes. If sometimes discussion takes long, that's fine, if it's an important feature. We should also clarify which are the necessary to work on. Like what are based on use cases and requirements
McCool: we should not mix prioritisation with the process
… we should give priority to certain topics of course
<Zakim> kaz, you wanted to react to kaz
<kaz> kaz: I'm not suggesting we mix prioritization with the process, but encouraging you all to see if the target topic (Pullrequest and Issue) is really required from the viewpoint of use cases and requirements before creating a Pullrequest.
Ege: we were already asking for decisions or discussions before, some PRs to TD were rejected due to that
Cristiano: We have narrowed it trivial changes but it should not only be that
Cristiano: I agree with Kaz that we should have some time like 1 week, even if all editors agree. This would allow others to comment
Ege: editorial changes section is just above
McCool: let's move some these up
McCool: (rearranges the text)
… I will also add that other members can contest the label
<cris_> +1
Ege: One editor can make the changes right?
McCool: yes, as long as you wait one week
McCool: review can start after labeling
Cristiano: I agree that labeling needs to be reviewed
Cristiano: I think after editors approving, the week starts
Cristiano: people may not know that the PR is ready
Ege: what if all PRs are drafts until the label
McCool: that makes it difficult to understand real drafts
Ege: or labels
McCool: that complicates it too much
McCool: without label is also a state
Ege: yes I agree, sounds good
<cris_> +1
<kaz> wot wg charter review
<kaz> 4.Chartering.md
<cris_> +1 for creating a template
Kaz: we should have use case for the basis of the need
McCool: I can add this is as a note
<kaz> kaz: also we should clarify the relationship between the GitHub discussion and the meeting discussion.
McCool: we can let reviews on the final policy
<cris_> ++1 for bots
<Zakim> dape, you wanted to inform about Github bots
dp: we can use bots to make the process smoother
Ege: +1 to daniel
Cristiano: it would be nicer if we include async discussions to policy changes
<kaz> kaz: can understand what Daniel and Cristiano mean, and so I also mentioned the mechanism for the group Chartering. However, if we really want to go for that direction, we need to clarify the relationship between the GitHub discussion and Telco discussion, also template for the GitHub Issues and Pullrequests. So I'd agree with McCool, we need more discussion about this.
McCool: this is about specifications, so let me add it to the title
chair decision policy PR
<kaz> chair-decision-process.md
<kaz> PR 1128 - [Policy] Move chair-decision-process.md from "proposals" to "policies"
McCool: we need to make a list of which things chairs can decide
McCool: the chairs meeting should be no more than one day before the main call
McCool: there is a quorum of two chairs to make a decision
<Zakim> Ege, you wanted to IG WG distinction
McCool: any comments about this policy?
Ege: is this for IG and WG?
McCool: this applies only to WG at this point
Ege: clarify the point of rejecting unsolicited IE applications
McCool: it's technically the job of chairs to ask for IE participation, there is no allowance for unsolicited IE applications
McCool: any objections to this policy?
Kaz: since the main call is for IG and WG, this policy should apply to both
McCool: we could define a separate policy for the IG
Kaz: we should separate the consensus part from the voting part
McCool: voting is only for emergencies
Kaz: the point is that the policy is still consensus based
Kaz: suggest that the team contact should get involved to help with reaching consensus
<kaz> W3C Process Document - 5.2.3 Deciding by Vote
<kaz> kaz: we should be very careful about "voting" like the W3C Process Document says
McCool: does anyone object to merging this PR now?
seb: +1 to merging the PR; we have been operating by consensus for years and this is not likely to be a problem
Kaz: we should not mention the details about voting, given the target topic is only about the IE application at the moment.
McCool: 2 out of 3 is more about quorum
McCool: since there is an objection, we should ask for suggested changes
twitter account issue with API changes
<kaz> wot-marketing PR 438 - Trying different Twitter/X integration
<Ege> https://
McCool: it seems like the bug doesn't show up everywhere
<kaz> (works from Canada, but not from Germany even with the incognito mode)
McCool: maybe it will stabilize in a day or 2
McCool: we should wait before making changes
Kaz: let's look into the problem more to understand what is broken
schedule changes
<kaz> Cancellations
McCool: wanted to make decisions about upcoming changes
… next Tuesday is a holiday in DE
… who is not planning to be available?
McCool: We will not cancel then
McCool: next is October 9th
… cancelling Scripting, Discovery, Security on Oct. 9th
McCool: November 23, Thanksgiving in US
… December 25
… January 1,2,3
… any objections?
Ege: Marketing call October 3rd is cancelled
McCool: will go to the calendar and cancel these dates
McCool: publication schedule review, please get testimonials done
… expect to have a resolution to publish next week
… publication October 5th
<Zakim> Ege, you wanted to mention marketing cancelled
Kaz: to meet that schedule, we also need specs and implementation reports
charter review
Kaz: we still had to send a confirmation message to the reviewers and I've already sent the message. However, we need to wait until October 2nd
… the next charter will start on October 3rd
Proposed Recommendations
McCool: has the TD draft been finalized yet? Is the rec document finalized?
Ege: the static version isn't rendered yet, Kaz will do that
Ege: index.html has all PRs merged
Kaz: Ege can make the static version and Kaz will check
Kaz: also need to create static versions for the other documents
… discovery and architecture
Implementation report - interoperability testing
McCool: how do we work this into the document?
… there used to be a matrix table
Kaz: we could add an explanation that we are doing interoperability testing at our plugtests
McCool: do we need to link to plugtests?
McCool: where does it go? it could go in the out of scope section
McCool: does anyone disagree with the wording on screen?
Kaz: could link to the plugtest and testing events
resource publication
McCool: need a few minutes to get this out of the way
McCool: need a way to preserve the resource files so they don't get accidentally modified
McCool: best would be copies into a repo where they are frozen
McCool: the file names need to be constructed to describe content types
McCool: the TD resources are using github URLs and need to use W3C URLs
… how can we get this done?
McCool: ready to do this for the discovery documents, hoping we can do this for TD also
… can we make a resolution to publish resources on October 4th
Ege: we have the PRs ready for resources but the structure is different
… we would use the publication directory for staging
McCool: we would rather use a separate directory for staging and a new repository
… wot-resources repository
… needs to be done by October 4th to publish by the 5th
Ege: we would only use the publication directory for temporary use
Kaz: we should not use the publication directory for stable resources
McCool: we are OK using the publication directory for staging
Kaz: if just for one week or so
McCool: will Kaz create a wot-resources repository?
… then the TFs will create PRs against that repo
<McCool> proposal: Use subdirectory under "publications" in each repo only for staging, but then copy to a special repo, wot-resources, which Kaz will create immediately.
<McCool> proposal: Use subdirectory under "publications" in each repo only for staging, but then copy resources to a special repo, wot-resources, which Kaz will create immediately, and which will be used for actual publication of the resources.
RESOLUTION: Use subdirectory under "publications" in each repo only for staging, but then copy resources to a special repo, wot-resources, which Kaz will create immediately, and which will be used for actual publication of the resources.
<kaz> (Kaz has just created "wot-resoureces" repo, and adding the Chairs and Editors to the Team for it)
McCool: resolved, will create an email for one week review
Kaz: please record which part of the minutes have been reviewed
McCool: still need the review from TD TF
McCool: AOB?
… adjourned