15:04:36 <RRSAgent> RRSAgent has joined #wot-arch
15:04:36 <RRSAgent> logging to https://www.w3.org/2021/11/11-wot-arch-irc
15:05:12 <kaz> meeting: WoT Architecture
15:05:28 <Mizushima> Mizushima has joined #wot-arch
15:05:28 <kaz> present+ Kaz_Ashimura, Ben_Francis, Daniel_Peintner, Michael_Lagally
15:07:40 <kaz> present+ Tomoaki_Mizushima
15:08:13 <dape> dape has joined #wot-arch
15:09:10 <kaz> q+
15:10:56 <kaz> ack k
15:12:01 <kaz> topic: Agenda
15:12:13 <dape> Kaz/ML: Agenda bashing
15:12:35 <dape> TOPIC: Charter extension
15:12:44 <kaz> present+ Sebastian_Kaebisch
15:12:53 <kaz> https://github.com/w3c/wot/blob/wg-2021-extension-plan/charters/wg-2021-extension-plan.md
15:13:28 <kaz> chair: Lagally
15:13:58 <dape> TOPIC: Minutes review
15:14:04 <dape> -> https://www.w3.org/2021/11/04-wot-arch-minutes.html
15:14:27 <mjk> mjk has joined #wot-arch
15:14:29 <kaz> s/TOPIC: Charter extension/kaz: would suggest we check the WG Charter extension plan right after the minutes review/
15:14:46 <kaz> s/html/html Nov-4/
15:16:35 <kaz> present+ Ryuichi_Matsukura
15:16:43 <kaz> rrsagent, make log public
15:16:46 <kaz> rrsagent, draft minutes
15:16:46 <RRSAgent> I have made the request to generate https://www.w3.org/2021/11/11-wot-arch-minutes.html kaz
15:17:34 <kaz> i/Agenda bashing/scribenick: dape/
15:17:35 <kaz> rrsagent, draft minutes
15:17:35 <RRSAgent> I have made the request to generate https://www.w3.org/2021/11/11-wot-arch-minutes.html kaz
15:18:02 <dape> ML: Any objections?
15:18:23 <dape> -> no objections -> minutes approved
15:18:41 <dape> TOPIC: Charter extension (cont.)
15:18:45 <dape> q+
15:18:48 <kaz> s/Charter/WG Charter/
15:19:01 <kaz> -> https://github.com/w3c/wot/blob/wg-2021-extension-plan/charters/wg-2021-extension-plan.md Extension plan
15:19:04 <kaz> q?
15:19:04 <dape> ML: 10 steps
15:19:24 <dape> ... 0. Clarify normative sections
15:19:30 <dape> ... 1. roll back
15:19:41 <dape> ... 2. normative feature freeze
15:20:03 <dape> s/normative feature freeze/normative feature freeze for TD & arch
15:20:25 <dape> ... 3. start to get wide review
15:20:46 <kaz> [[
15:20:46 <kaz> Clarify which normative sections should be included or should be improved in TD 1.1, Profile, Arch 1.1, and Discovery by end-Nov
15:20:46 <dape> ML: idea was to have 123 mo extension
15:20:49 <kaz> Roll back TD spec to 1.1 (1.0 compatible) features by Nov 30
15:20:51 <kaz> Normative features freeze TD 1.1 & Architecture spec by Dec 15
15:20:53 <kaz> Start to get wide review including TAG, Accessibilty, Privacy, Security, and Internationalization to review TD 1.1 draft (note: might take 6 month)
15:20:54 <dape> ... instead of 6 mo
15:20:56 <kaz> Normative features freeze Discovery spec by Dec 15
15:20:58 <kaz> Feature freeze Profile spec by Jan 31
15:21:00 <kaz> Testfest in mid-Feb
15:21:02 <kaz> CR transition in mid-March
15:21:04 <kaz> PR transition in mid-April
15:21:06 <kaz> REC transition before end of extended charter end of July
15:21:08 <kaz> ]]
15:21:10 <kaz> s/123/12/
15:21:33 <kaz> q+
15:22:02 <kaz> ack d
15:22:04 <benfrancis> q+
15:22:12 <kaz> dp: quick comment
15:22:22 <kaz> ... preliminary decision for 12mo
15:22:28 <kaz> ... but this plan still says 6mo
15:22:36 <dape> ack dape
15:22:43 <kaz> i/quick/scribenick: kaz/
15:22:47 <kaz> ml: right
15:23:16 <dape> ML: made preliminary decision yesterday. Should decide today
15:23:31 <kaz> q-
15:23:33 <kaz> q+
15:23:41 <dape> BF: 6 month time line
15:24:02 <dape> ... does it affect the timeline if we go with 12 mo
15:24:18 <sebastia_> q+
15:24:20 <dape> ... v2.0 delayed
15:24:35 <dape> ... can we recharter if we finish early
15:24:49 <kaz> -> https://www.w3.org/2021/11/10-wot-minutes.html#r01 main call preliminary resolution
15:25:11 <dape> Kaz: We will ask for 12 mo extension
15:25:21 <dape> ... but we would like to keep 6 mo schedule
15:25:31 <dape> ... just for potential delay
15:26:20 <dape> ... PLH agreed with new plan
15:26:51 <dape> ... we can renew charter for 2.0 in parallel
15:26:55 <dape> BF: Sounds good
15:27:21 <dape> ... can we have a new charter earlier
15:27:26 <dape> Kaz: Yes
15:27:33 <dape> q?
15:27:37 <kaz> ack b
15:27:37 <dape> ack benfrancis
15:27:38 <kaz> ack k
15:28:02 <kaz> i/made prelmin/scribenick: dape/
15:28:16 <kaz> rrsagent, draft minutes
15:28:16 <RRSAgent> I have made the request to generate https://www.w3.org/2021/11/11-wot-arch-minutes.html kaz
15:28:18 <dape> ML: final resolution should make clear that we stick to freeze dates
15:28:52 <kaz> s/ (cont.)//
15:28:54 <kaz> rrsagent, draft minutes
15:28:54 <RRSAgent> I have made the request to generate https://www.w3.org/2021/11/11-wot-arch-minutes.html kaz
15:29:39 <dape> SK: would like to mention that my goal is to release v1.1 as soon as possible
15:29:40 <kaz> i/made prel/scribenick: dape/
15:29:43 <kaz> rrsagent, draft minutes
15:29:43 <RRSAgent> I have made the request to generate https://www.w3.org/2021/11/11-wot-arch-minutes.html kaz
15:29:57 <kaz> q?
15:29:58 <kaz> ack s
15:30:03 <kaz> q+
15:30:27 <dape> ... can start work for 2.0 earlier
15:30:45 <kaz> present+ Ege_Korkan
15:30:45 <dape> ML: TD finalized within 12 months ?
15:30:59 <dape> SK: That's the plan
15:31:11 <dape> ... we started already to work on 2.0
15:31:42 <dape> ML: 2.0 may have impact on other documents
15:32:27 <dape> Kaz: we concentrate on 1.1 in this charter period
15:32:45 <dape> ... should check deadlines periodically
15:33:13 <kaz> ack k
15:33:14 <kaz> q+
15:33:18 <dape> ML: Why don't we make a clear decision that 2.0 does not go into this charter
15:33:24 <benfrancis> q+
15:33:26 <dape> ... put 2.0 in new charter
15:33:53 <dape> Kaz: we are talking about potential features in 2.0
15:34:03 <kaz> ack k
15:34:28 <dape> SK: backwards compatibility issues with 2.0
15:34:50 <kaz> s/in 2.0/in 2.0 but we've been deferring those features to the next Charter period by adding the "2.0" label./
15:34:57 <dape> BF: 2 separate documents in current charter, TD update and TD next
15:35:01 <kaz> present+ Michael_Koster
15:35:10 <kaz> q?
15:35:12 <kaz> ack b
15:35:30 <dape> SK: Correct. Other documents currently should rely on 1.1 for now
15:35:32 <kaz> s/we are talking/we've been talking/
15:35:52 <kaz> s/features in 2.0/features for TD 2.0/
15:36:04 <kaz> rrsagent, draft minutes
15:36:04 <RRSAgent> I have made the request to generate https://www.w3.org/2021/11/11-wot-arch-minutes.html kaz
15:36:05 <dape> ML: Suggest to identify use-cases for new features
15:36:27 <kaz> s|i/made prelmin/scribenick: dape/||
15:37:05 <kaz> q+
15:37:21 <dape> ML: does anyone have concern with 12 m extension?
15:38:10 <dape> ML: <adds note about keeping 6 m schedule>
15:38:50 <kaz> [[<sebastian> preliminary resolution: the group decide to extend the current WG charter for 12month. A final decision will be made in tomorrow's Architecture call. An email will be sent to the WG group as reminder.]]
15:39:13 <mlagally> proposal: call participants agree to the 12 months WG2021 Extension Plan as described in https://github.com/w3c/wot/blob/wg-2021-extension-plan/charters/wg-2021-extension-plan.md
15:40:03 <mlagally> proposal: call participants agree to the 12 months WG2021 Extension Plan as described in https://github.com/w3c/wot/blob/wg-2021-extension-plan/charters/wg-2021-extension-plan.md. This has been already prelimiarily approved in yesterdays main call.
15:40:47 <mlagally> resolution: call participants agreed to the 12 months WG2021 Extension Plan as described in https://github.com/w3c/wot/blob/wg-2021-extension-plan/charters/wg-2021-extension-plan.md. This has been already preliminarily approved in yesterdays main call.
15:41:17 <dape> TOPIC: Clarify specification structure
15:42:49 <dape> SUBTOPIC: Remove External TD representations section
15:42:55 <dape> -> https://github.com/w3c/wot-profile/pull/123
15:44:59 <dape> ML: Canonical TD removed from TD and from profile?
15:45:06 <dape> ... not sure if we should do that
15:45:19 <dape> BF: repeating information from TD spec
15:45:28 <dape> ... canonical no longer used in profile
15:45:51 <kaz> q?
15:45:53 <kaz> ack k
15:45:58 <kaz> qq+ sebastian
15:46:05 <kaz> q- sebastian
15:46:29 <dape> SK: if Canonical text is in TD we should remove it from profile
15:46:56 <dape> ML: Does it explain all aspects like pure JSON parser is sufficient ?
15:47:08 <dape> SK: Yes, basic setup of TD
15:47:40 <dape> ML: What is default encoding format for TD?
15:47:49 <dape> SK: JSON-based serialization
15:48:05 <kaz> -> https://pr-preview.s3.amazonaws.com/w3c/wot-profile/123/d51d816...benfrancis:8167e8b.html#error-responses diff version - 5.2.4 Error Responses
15:48:13 <Ege> Ege has joined #wot-arch
15:48:14 <dape> BF: default is JSON, but it can be JSON-LS
15:48:20 <kaz> present+ Fady_Salama
15:48:27 <kaz> rrsagent, draft minutes
15:48:27 <RRSAgent> I have made the request to generate https://www.w3.org/2021/11/11-wot-arch-minutes.html kaz
15:48:28 <dape> s/JSON-LS/JSON-LD annotated
15:48:35 <dape> q?
15:49:11 <dape> ML: On canonical TD mentioning.  I think having it in profile makes sense.
15:49:34 <sebastia_> q+
15:49:40 <dape> ... heard concerns about implementing canonical TD
15:49:54 <dape> ... was confusing to me
15:51:03 <dape> BF: no mentioning of canonical TD any longer, therefore I removed it
15:51:24 <dape> ML: The content is not complete yet. we need to keep that in mind
15:51:50 <dape> SK: at the moment canonical TD is covered by the TD spec
15:52:01 <dape> ... no need to repeat in profile
15:52:19 <dape> ML: Feature is at risk, right?
15:52:28 <kaz> q?
15:52:31 <kaz> q+
15:52:32 <dape> SK: yes, depends on available implementations
15:52:35 <kaz> ack s
15:54:10 <dape> ML: The text in profile is not normative
15:54:23 <dape> BF: Yes, but it is in conflict with the TD text
15:54:28 <sebastia_> https://w3c.github.io/wot-thing-description/#canonicalization-serialization-json
15:54:43 <dape> ML: Suggest to wait till TD includes the feature (or not)
15:55:21 <dape> BF: Unfortunately it is a different specification
15:57:00 <dape> ML: To make progress. Let's wait until we know how canonical TD moves on in the TD spec
15:57:15 <sebastia_> q+
15:57:20 <dape> BF: it is not used in the profile as of now
15:57:35 <dape> ML: Plan was to have a signing TD section
15:57:52 <dape> BF: I don't think that belongs to profile
15:58:01 <kaz> ack seba
15:58:08 <dape> SK: McCool worked on signing document
15:58:34 <dape> ... it turns out it is not ready
15:58:51 <dape> ... we should not refer to
15:59:01 <dape> ... standardized solution by W3C is going to come
15:59:23 <dape> ... I agree with Ben, signing should not go into profile
15:59:26 <kaz> s/worked/is working/
16:00:05 <dape> SK: The canonical TD section will be kept until we start PR transition
16:00:10 <dape> ... mid april
16:00:30 <dape> ... after that we will be removing it (IF we don't have enough implementations)
16:00:56 <kaz> q?
16:01:55 <dape> ML: its unfortunate to have forward references to documents that are to be written in the future
16:01:56 <benfrancis> https://w3c.github.io/wot-thing-description/#canonicalization-serialization-json
16:02:26 <dape> SK: We should just be sure that text is compliant
16:02:46 <dape> ... should also avoid redundancy
16:03:00 <dape> ML: Yes, and misalignments
16:03:22 <dape> ML: Okay, let's approve PR#123
16:04:25 <dape> Kaz: Do we want to have this feature normatively
16:04:32 <dape> ... we should decide that first
16:04:55 <dape> ML: Normative canonical TD format does make sense
16:05:27 <dape> Kaz: I see, since we cannot deal with it now we should move it to open issues
16:06:07 <kaz> q?
16:06:09 <kaz> ack k
16:06:49 <kaz> q+ dape
16:06:52 <kaz> ack d
16:07:13 <kaz> q+
16:07:38 <dape> DP: Canonical TD feature is needed, but for the TD in general, not for the profile only
16:07:44 <kaz> ack k
16:08:12 <mlagally> https://github.com/w3c/wot-profile/issues/132
16:08:20 <dape> ML: let's create an issue (see above)
16:08:48 <dape> SUBTOPIC: Add Identifier section to Core Profile
16:08:55 <dape> -> https://github.com/w3c/wot-profile/pull/117
16:08:58 <kaz> i/132/kaz: right. the purpose of WoT Profile is a collection of subsets of features from the WoT specs, so we don't need to redefine any features within the WoT Profile itself./
16:09:14 <kaz> rrsagent, draft miutes
16:09:14 <RRSAgent> I'm logging. I don't understand 'draft miutes', kaz.  Try /msg RRSAgent help
16:09:19 <kaz> s/rrsagent, draft miutes//
16:09:23 <kaz> rrsagent, draft minutes
16:09:23 <RRSAgent> I have made the request to generate https://www.w3.org/2021/11/11-wot-arch-minutes.html kaz
16:09:26 <dape> BF: Goal of profile spec is adhoc interop
16:09:42 <dape> ... currently there is no text in profile how to find/retrieve TD
16:10:02 <kaz> i/the purpose/scribenick: kaz/
16:10:10 <kaz> i/let's cr/scribenick: dape/
16:10:13 <kaz> rrsagent, draft minutes
16:10:14 <RRSAgent> I have made the request to generate https://www.w3.org/2021/11/11-wot-arch-minutes.html kaz
16:10:25 <dape> ... simplest mechanism is "direct" discovery
16:10:48 <dape> ... that's all what the addition says, URL retrievable
16:10:57 <sebastia_> q+
16:10:59 <dape> q?
16:11:09 <kaz> ack s
16:11:26 <dape> SK: I miss a convention how the URL looks like
16:11:44 <dape> ... like well-known pattern known from CoAP
16:11:56 <dape> ... a pre-defined URL would be good
16:12:03 <dape> ... or root address
16:12:26 <dape> BF: discovery spec does propose well-known pattern
16:12:28 <dape> q+
16:13:04 <kaz> -> https://pr-preview.s3.amazonaws.com/w3c/wot-profile/121/d51d816...benfrancis:153a554.html#discovery diff version - 5.3  Discovery
16:13:07 <kaz> ack d
16:13:21 <kaz> qq+ ben
16:13:23 <kaz> q- ben
16:13:24 <dape> DP: well-known is based on host level
16:13:45 <dape> ... does not work for multiple things
16:14:17 <dape> BF: in discovery spec are 2 stages
16:14:35 <dape> ... well-known in introduction mechanism
16:14:47 <dape> ... thing or directory
16:14:58 <dape> ... in case of multiple things you need to have a directory
16:15:06 <dape> ... hence it is not a good fit here
16:15:54 <dape> ML: requirement of thing or TD
16:16:19 <dape> BF: Does not matter, can be hosted by itself or by a cloud service
16:16:36 <dape> s/hosted by itself/hosted by the thing itself
16:17:10 <dape> ML: Why do we require HTTP url
16:17:21 <dape> ... could be a file ?
16:18:37 <dape> BF: I argue that if TD cannot be retrieved via HTTP it is not a WebThing, rather a thing
16:18:57 <dape> ML: I can see many use-cases
16:19:53 <sebastia_> q+
16:19:55 <dape> ... we put constraints and forbid other scenarios
16:20:07 <dape> ... out-of-band is fine for me
16:20:12 <kaz> q+
16:20:17 <dape> BF: I take the point
16:20:40 <dape> ... long-lasting issue to have a discovery section in profile
16:20:50 <dape> ... this is the simplest mechanism
16:21:16 <dape> ... if we think this is too much, I can live without
16:21:42 <dape> SK: out-of-the box interop raises the question where to get the TD
16:22:08 <dape> ... without such a requirement we miss that capability
16:22:19 <dape> q?
16:22:24 <dape> ack sebastia_
16:23:00 <dape> BF: This discovery mechanism is basic
16:23:15 <dape> ... DNS would be to much of a requirement
16:23:58 <dape> ML: I suggest we make things self-descriptive
16:24:14 <dape> .. known URL of thing should be sufficient
16:24:32 <dape> s/known URL/knowing URL
16:25:00 <dape> BF/SK: Not sure what is needed
16:25:22 <dape> ML: Simple, define fixed string property "td" that always reports TD
16:25:38 <dape> SK: Agree, but we do not need to define property
16:25:54 <dape> BF: IP address /domain still needs to be known
16:26:28 <dape> q?
16:26:44 <dape> ML: Mandatory endpoint
16:27:09 <dape> BF: What about multiple things on gateway (same hostname)
16:27:32 <kaz> -> https://w3c.github.io/wot-discovery/#introduction-mech WoT Discovery - 5. Introduction Mechanisms
16:27:36 <dape> SK: Master array
16:27:44 <dape> BF: Is a directory, right?
16:27:46 <dape> SK: Yes
16:28:34 <dape> Kaz: details of discovery should be described by discovery .. not here
16:28:37 <kaz> s/to much/too much/
16:28:54 <dape> ML: What is missing?
16:29:08 <dape> BF: Link, currently we reference direct
16:29:10 <kaz> s/by discovery/by the WoT Discovery document/
16:29:13 <benfrancis> https://w3c.github.io/wot-discovery/#introduction-mech
16:29:20 <dape> ... I am hearing we should reference well-known also
16:30:44 <dape> Kaz: direct + well-known for profile
16:30:56 <dape> ML: Question, do we enforce well-known scheme in profile
16:31:05 <kaz> s/for profile/for the Core Profile within the WoT Profile document./
16:31:06 <dape> BF: I am OK with that
16:31:22 <dape> ... tricky if gateway host multiple things
16:32:23 <dape> ... maybe having direct mandatory, well-known optional
16:33:07 <dape> SK: I don't think it helps, might miss IP
16:33:29 <dape> BF: I am fine with making both mechanism mandatory
16:33:51 <kaz> q+ ege
16:34:07 <dape> ... I just want to make clear that requires directory service
16:34:45 <dape> Ege: https://esiremotelab.esi.ei.tum.de:8081/ shares array of TDs
16:35:51 <dape> ... points to TDs
16:36:01 <dape> BF: Does not work with well-knonw
16:36:12 <dape> s/well-knonw/well-known
16:36:22 <kaz> ack k
16:36:23 <dape> ... for multiple things
16:36:24 <kaz> ack e
16:36:26 <kaz> q+ seb
16:36:30 <kaz> ack seb
16:36:43 <kaz> q+
16:36:50 <dape> SK: topic should be covered by discovery spec
16:37:09 <dape> Ege: well-known works well in local network
16:37:42 <dape> SK: Just a list of links
16:37:48 <dape> ... should have links container
16:38:32 <dape> similar to http://plugfest.thingweb.io:8083/
16:39:13 <dape> ML: Couple of options
16:39:27 <dape> ... we don't consider aggregates things
16:39:54 <dape> ... container aggregation with links container
16:40:10 <dape> ... not sure about complexity
16:40:23 <kaz> q?
16:40:49 <dape> ML: Suggest to have self-description
16:40:50 <kaz> qq+ ben
16:40:57 <kaz> q- ben
16:41:03 <dape> BF: I think you mean well-known uri ?
16:41:07 <dape> ML: Yes
16:41:17 <dape> BF: Okay, can work on that
16:41:33 <dape> ... still see issues with hosting multiple things
16:41:55 <dape> Kaz: profile can have both, direct and well-known?
16:43:47 <dape> ... the directory still needs updates
16:44:10 <kaz> s/the directory/the problem here is rather that the WoT Discovery spec/
16:44:22 <dape> ML: I think the direction is clear. We want a link to get a TD without significant overhead
16:44:29 <kaz> q?
16:44:31 <kaz> ack k
16:45:13 <dape> BF: I can work on the topic
16:45:53 <dape> SUBTOPIC: Add use cases for profiles section
16:45:55 <dape> -> https://github.com/w3c/wot-profile/pull/129
16:46:10 <dape> ML: I have to PRs on use-cases
16:46:28 <dape> ... motivate
16:46:39 <benfrancis> q+
16:46:49 <sebastia_> q+
16:47:05 <dape> ML: other PR is https://github.com/w3c/wot-profile/pull/130
16:47:16 <mlagally> https://github.com/w3c/wot-profile/pull/130
16:47:27 <dape> ...please provide feedback
16:47:29 <mlagally> Please review until next week.
16:47:38 <dape> q?
16:47:59 <dape> BF: I looked at the PR
16:48:16 <dape> ... initial feedback seems to be a duplication of text
16:48:30 <dape> ... other specs don't have use-cases section
16:48:55 <dape> ... not sure if we need to have it in profile
16:49:18 <dape> ML: Text comes from use-case document
16:49:26 <kaz> q?
16:49:28 <dape> ... help to understand scope and context
16:49:28 <kaz> ack b
16:49:32 <dape> q?
16:49:54 <dape> SK: Similar comment. I think we have use-case document
16:50:05 <dape> ... maybe we can reference use-case sections
16:50:24 <dape> ... I would like to see "who benefits from the profile"
16:50:34 <dape> ... motivation is somewhat missing
16:50:46 <kaz> -> https://pr-preview.s3.amazonaws.com/w3c/wot-profile/130/d51d816...47508a1.html#profile-use-cases diff - 4. Use Cases and Requirements
16:51:13 <kaz> q+
16:51:15 <dape> ML: It is a summary from use-case document
16:51:40 <kaz> q?
16:51:49 <dape> ... just pointing to use case document is not enough
16:52:09 <kaz> ack seb
16:52:09 <dape> Kaz: Summary text can be included but maybe in introduction section
16:52:10 <kaz> ack k
16:52:26 <sebastia_> q+
16:53:12 <kaz> ack s
16:53:38 <dape> SK: I am concerned about amount of topics
16:53:55 <kaz> q+
16:54:05 <dape> ... I think we should concentrate on technical decisions
16:54:21 <dape> ML: No new details, helps the reader
16:54:50 <dape> SK: Anyhow, should put our focus on technical discussions
16:55:27 <kaz> https://pr-preview.s3.amazonaws.com/w3c/wot-profile/130/d51d816...47508a1.html#profile-use-cases
16:56:14 <kaz> kaz: anyway, this is rather additional rationale description for WoT Profile in general
16:56:36 <kaz> ... so should be included in the Introduction section after shrinking the text a bit
16:56:47 <kaz> ml: please look at the text also
16:57:49 <kaz> topic: Next call
16:58:15 <kaz> ml: we've done PR 123, 117, 121, 131 and 129
16:58:31 <kaz> ... would continue the discussion during the next call
16:58:45 <kaz> bf: would like to think about the decision making policy again
16:58:57 <kaz> ... currently we make decisions during the weekly calls
16:59:23 <kaz> i/anyway/scribenick: kaz/
16:59:57 <kaz> ml: from my viewpoint, the mechanism works good so far
17:00:23 <kaz> ... would like to hear from everybody for opinions, though
17:01:09 <benfrancis> q+
17:01:33 <kaz> kaz: we need to identify which Issues/PRs need what level of discussion
17:01:35 <kaz> ack k
17:02:18 <kaz> bf: note that I've split my big PR into several smaller PRs for easier review
17:02:46 <kaz> ml: let's discuss the potential new procedure for making decision during the main call
17:02:46 <kaz> bf: ok
17:02:48 <kaz> [adjourned]
17:02:54 <kaz> rrsagent, draft minutes
17:02:54 <RRSAgent> I have made the request to generate https://www.w3.org/2021/11/11-wot-arch-minutes.html kaz
17:10:24 <sebastian> sebastian has joined #wot-arch
17:11:07 <sebastia_> sebastia_ has joined #wot-arch