14:46:40 <RRSAgent> RRSAgent has joined #updatable-rec
14:46:45 <RRSAgent> logging to https://www.w3.org/2024/09/25-updatable-rec-irc
14:46:45 <tpac-breakout-bot> RRSAgent, do not leave
14:46:46 <tpac-breakout-bot> RRSAgent, make logs public
14:46:47 <tpac-breakout-bot> Meeting: Simplifying the Updatable REC Process
14:46:47 <tpac-breakout-bot> Chair: Marcos Caceres
14:46:47 <tpac-breakout-bot> Agenda: https://github.com/w3c/tpac2024-breakouts/issues/11
14:46:47 <Zakim> Zakim has joined #updatable-rec
14:46:48 <tpac-breakout-bot> Zakim, clear agenda
14:46:48 <Zakim> agenda cleared
14:46:48 <tpac-breakout-bot> Zakim, agenda+ Pick a scribe
14:46:49 <Zakim> agendum 1 added
14:46:49 <tpac-breakout-bot> Zakim, agenda+ Reminders: code of conduct, health policies, recorded session policy
14:46:49 <Zakim> agendum 2 added
14:46:49 <tpac-breakout-bot> Zakim, agenda+ Goal of this session
14:46:50 <Zakim> agendum 3 added
14:46:50 <tpac-breakout-bot> Zakim, agenda+ Discussion
14:46:50 <Zakim> agendum 4 added
14:46:50 <tpac-breakout-bot> Zakim, agenda+ Next steps / where discussion continues
14:46:51 <Zakim> agendum 5 added
14:46:51 <tpac-breakout-bot> tpac-breakout-bot has left #updatable-rec
17:28:13 <michaelchampion> michaelchampion has joined #updatable-rec
17:28:56 <michaelchampion> michaelchampion has joined #updatable-rec
18:09:34 <gkellogg> gkellogg has joined #updatable-rec
18:16:29 <florian_irc> florian_irc has joined #updatable-rec
18:16:31 <astearns> astearns has joined #updatable-rec
18:16:34 <fantasai> fantasai has joined #updatable-rec
18:16:46 <Neil> Neil has joined #updatable-rec
18:17:20 <JKRhb> JKRhb has joined #updatable-rec
18:17:28 <nigel> nigel has joined #updatable-rec
18:17:46 <JKRhb> JKRhb has left #updatable-rec
18:17:47 <denis> denis has joined #updatable-rec
18:17:58 <nigel> present+ Nigel_Megitt
18:18:09 <nigel> rrsagent, make minutes
18:18:10 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/25-updatable-rec-minutes.html nigel
18:18:17 <gkellogg> present+ Gregg_Kellogg
18:18:18 <dom> dom has joined #updatable-rec
18:18:18 <dom> scribe+
18:18:30 <nigel> rrsagent, make logs public
18:19:06 <dom> Marcos: who isn't familiar with the updateable rec process yet?
18:19:11 <dom> nigel: I'm in the early days of using it
18:19:34 <nigel> Agenda: https://www.w3.org/events/meetings/17d0482c-06fa-4fab-8085-387a02dcce35/
18:19:39 <dom> Marcos: the assumptions that underpin the process and the experience in practice, what turned out the complexity; if going down this path, choose wisely
18:20:05 <fantasai> github: https://github.com/w3c/process/issues/866
18:20:06 <Neil> present+
18:20:08 <dom> ... more clarity on consequences and expectations of that process are likely needed
18:20:15 <nigel> Agenda: https://github.com/w3c/tpac2024-breakouts/issues/11
18:20:29 <dom> .... being able to show what changes are, their status is good
18:20:36 <dom> ... there may be alternative approaches
18:20:53 <dom> ... with tooling, social changes, or even more radical changes
18:21:14 <dom> .... we've had specs that tried using it but had to stop
18:21:29 <dom> ... we managed to do it with Geolocation, but this was still a struggle
18:21:39 <florian_irc> q+
18:21:44 <dom> ... having to write manual diffs is not very practical
18:21:54 <dom> q+ to relate the WebRTC experience
18:22:09 <astearns> ack fantasai
18:22:11 <dom> fantasai: the Process require the text of the spec go through wide review, implemetnation review, AC review, etc
18:22:33 <Neil> q+
18:22:37 <dom> ... the problem we want to solve is that doing this all took so long that it didn't get reflected to the Recommendation documnet (only in the editors draft)
18:22:52 <dom> ... the reqiurement is to annotate the change as identified correction or addition
18:23:10 <dom> ... and once they've been vetted and proved to match the Rec qualifications, they can be folded in the main Rec
18:23:30 <dom> .... the process doesn't mandate anything about how these annotations are maintained, only that they need to be reviewable
18:23:49 <dom> ... and the normative content of the Rec is the one that has gone through the proper review
18:24:03 <dom> ... Marcos has identified that the generation of the diff markup is complex to manage
18:24:44 <dom> ... There hasn't been a lot of training, not a lot of experience sharing on what may need to change to make this more workable
18:24:59 <astearns> ack florian_irc
18:25:15 <dom> florian_irc: as we think through this, let's distinguish what can be done without process change
18:25:49 <dom> .... things that need process changes, either because they're not needed, or because they're too constraining to make it workable
18:26:20 <nigel> q+ to say there's a scale of usage, and marketing/information issue
18:26:37 <dom> ... we should approach process changes carefully
18:26:38 <fantasai> scribe+
18:27:12 <dom> marcos: the Process itself is a bit hard to follow
18:27:34 <dom> ... another aspect is that how the requirements are met: retaining Rec quality is the ultimate goal
18:27:54 <dom> ... but his may be achiveable through other approaches (and thus Process changes)
18:29:08 <plh> plh has joined #updatable-rec
18:29:15 <dom> ... as one of the first adopters of the process, w3c/payment-request#996 is an example of managing the diff wasn't suitable
18:29:55 <dom> ... we ended up choosing to go back to CR
18:30:20 <dom> fantasai: note that we're proposing to drop PR which may help with that process
18:30:22 <plh> q+ plh
18:30:36 <fantasai> marcos: Dom, you had something about webRTC?
18:30:36 <nigel> scribe+ nigel
18:30:48 <nigel> Dom: WebRTC was published in 2021
18:30:48 <fantasai> dom: It was published in 2021, and we identified 48 changes to spec
18:31:03 <fantasai> ... in that process we've ben experimenting with combination of tooling, process management
18:31:15 <fantasai> ... we were able to generate the diff automatically from the base recommendation using some magic script from ECMA
18:31:38 <fantasai> ... I think this made it possible, the WG agreed yesterday to bring 20-ish of those candidate amendments as proposed amendments
18:32:00 <fantasai> ... it has also helped in some ways to structure discussion on the changes, because forced to discuss are these editorial or substantive, do we have tests etc.
18:32:03 <fantasai> ... it also proved useful
18:32:14 <florian_irc> q+
18:32:17 <fantasai> ... but feedback from WG was, I don't know that we would do that if you (dom) were not managing the process
18:32:21 <fantasai> ... I'm concerned about that
18:32:25 <astearns> ack dom
18:32:25 <Zakim> dom, you wanted to relate the WebRTC experience
18:32:41 <fantasai> ... my tooling is a bit experimental, can make some simplifications
18:32:46 <fantasai> ... some of it is training and getting familiarity
18:32:55 <fantasai> ... I' mthe only one in the WG that has full understanidng of post-REC process
18:33:02 <fantasai> ... but still a lot of familiarization needed
18:33:16 <fantasai> ... but we should ask ourself if the process is fit for purpose, given few cases of success
18:33:33 <fantasai> ... but I'm a lot more optimistic today than 6 months ago, due to progress in tooling
18:33:41 <fantasai> ... but we need more community support for ths process
18:33:48 <fantasai> s/ths/this/
18:34:01 <fantasai> ... sharing experience, building better tooling -- my tooling is a bit scrappy
18:34:05 <fantasai> ... building into regular spec tooling
18:34:10 <fantasai> ... integrate into GH management
18:34:24 <fantasai> ... I think if we want to really claim that we have a solution to that problem space, need more attention and resources
18:34:49 <fantasai> ... hopefully can experiment faster pace if we can strucutre commmunity effort
18:35:04 <fantasai> fantasai: can you tell us what you did?
18:35:11 <fantasai> dom: When you make normative change to WebRTC
18:35:21 <fantasai> ... identify it as such
18:35:35 <fantasai> ... for each PR that is made to the REC, there's an expectation that your document this JSON file
18:35:42 <fantasai> ... what kind of amendment is it?
18:35:49 <fantasai> ... give a human-level description of the change
18:36:06 <fantasai> ... document the testcases that demonstrate the change was implemented
18:36:12 <fantasai> ... link to the PR in WPT
18:36:42 <fantasai> ... for anything not determined as editorial -- if you don't document this PR with the amendment -- it will be flagged as not ready for merging
18:37:00 <plh> qq+ to ask one clarification
18:37:35 <fantasai> ... this allows generating the list of candidate/proposed amendments with links to relevant PRs and tests
18:37:40 <fantasai> ... which will help for LC review process
18:38:08 <fantasai> ... you can see that for each change it shows the annotations and the diff
18:38:17 <fantasai> ... it takes the markup form the base REC, which we saved in the repo
18:38:30 <fantasai> ... compares it to new markup, and generates diff markup by JS
18:38:50 <fantasai> ... just need to say "this section with id X is new version of id X, or addition to the REC"
18:39:02 <fantasai> marcos: you still need the insertions and deletions
18:39:07 <fantasai> dom: They're generated from the PR
18:39:23 <fantasai> florian_irc: JSON is manually written, and it generates the diff
18:39:26 <plh> q-
18:39:30 <gkellogg> q+
18:39:31 <fantasai> dom: I think can further simplify also with conventions
18:39:38 <fantasai> dom: I haven't tried to get us there
18:39:47 <florian_irc> s/generates the diff/generates the diff from the pull request
18:39:57 <fantasai> ... but in terms of editor's work, instead of having to deal with diff markup, you just have to deal with picking the right IDs for the changes in your document
18:40:05 <fantasai> ... won't say that this is trivial -- initial version wasn't easy to  use
18:40:10 <plh> dom++
18:40:13 <fantasai> ... but at this point it's vastly easier than doing manual markup
18:40:17 <fantasai> s/dom:/.../
18:40:26 <florian_irc> q?
18:40:46 <fantasai> Neil: Neil Soiffer, MathWG
18:40:56 <fantasai> ... I'm mainly here to learn, so not completely up to date on the proposals
18:41:09 <fantasai> ... but I know a number of the changes in our 25 years were simply editorail
18:41:12 <florian_irc> qq+
18:41:19 <fantasai> ... was this process simpler or harder, or changes don't matter if clarifications
18:41:32 <fantasai> dom: If class 1 or 2 changes, super simpler, just republish
18:41:33 <florian_irc> ack florian_irc
18:41:33 <Zakim> florian_irc, you wanted to react to dom
18:41:41 <fantasai> Neil: we had insertions and deletions to track our changes, build up and make things harder to edit
18:41:48 <Marcos> Marcos has joined #updatable-rec
18:41:56 <fantasai> fantasai: Yes, that's what we have now
18:41:58 <dom> ack Neil
18:42:01 <dom> ack Nigel
18:42:01 <Zakim> nigel, you wanted to say there's a scale of usage, and marketing/information issue
18:42:04 <Marcos> q+
18:42:17 <fantasai> nigel: My observation is there's a sense, it's been 3 years and everything should be easy
18:42:30 <fantasai> ... but changing how REC publication work and bringing the community along has taken awhile and still not done
18:42:33 <florian_irc> [Process fir REC revision is documented here: https://www.w3.org/policies/process/#revising-rec ]
18:42:34 <fantasai> ... I think that's OK
18:42:40 <fantasai> ... things like more mature tooling is part of the ansewr
18:42:44 <sideshowbarker> sideshowbarker has joined #updatable-rec
18:42:47 <fantasai> ... but wanted to reflect on... thread in Process CG
18:42:53 <sideshowbarker> RRSAgent, make minutes
18:42:54 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/25-updatable-rec-minutes.html sideshowbarker
18:43:02 <fantasai> ... where talking about perpetual CR as being the answer to living standards
18:43:12 <florian_irc> q?
18:43:12 <sideshowbarker> q+ to comment
18:43:14 <fantasai> ... tried to suggest that updateable REC is better; what isn't working in updateable REC?
18:43:23 <fantasai> ... and I've totally failed to get an answre
18:43:37 <fantasai> ... but one point that came out was more about marketing and documentation and raising priority of the option
18:43:43 <sideshowbarker> I disagree that Nigel has totally failed to get an answer
18:43:53 <fantasai> ... in the thread I refer to an updateable REC, and response was "that's not a thing in the process"
18:44:30 <fantasai> ... if you set the status correctly in ReSpec, it knows how to do it
18:44:38 <fantasai> ... but not clear in the Process because no term for it
18:44:50 <fantasai> ... Maybe have a definition
18:45:01 <florian_irc> qq+
18:45:19 <fantasai> florian_irc: we've done part of what you asked
18:45:32 <fantasai> ... as part of dropping PR phase, we did some editorial work to make it more visible
18:45:43 <fantasai> ... but remember that *every* REC allows for changes
18:46:06 <fantasai> ... it's about opting into changes that allow new features -- that is not allowed by default
18:46:15 <florian_irc> ack florian_irc
18:46:15 <Zakim> florian_irc, you wanted to react to nigel
18:46:15 <dom> ack florian_irc
18:46:29 <fantasai> plh: Thank Dom for making progress on tooling
18:46:31 <dom> qa+ florian_irc
18:46:33 <fantasai> ... today WGs are avoiding that process
18:46:36 <dom> ack plh
18:46:40 <dom> q+ florian_irc
18:46:41 <fantasai> ... webAudio isn't going down that road, e.g.
18:46:49 <dom> q- florian_irc
18:46:54 <dom> qq+ florian_irc
18:47:06 <fantasai> ... as fantasai alluded, there's what Process says and how we implement it, and these are two different things
18:47:13 <fantasai> ... sometimes we just need to update the Guidebook
18:47:24 <fantasai> ... I don't think we have any documentation in Guide about how to update RECs
18:47:36 <fantasai> ... idk if the solution proposed by Dom woudl work on Marcos' PR
18:47:47 <fantasai> ... but we need something simple, because it's hard to find editors at all
18:48:14 <fantasai> ... problem shouldn't be editing mechanics, but content of the spec
18:48:17 <dom> ack florian_irc
18:48:18 <Zakim> florian_irc, you wanted to react to plh
18:48:33 <fantasai> florian_irc: in addition to being familiar with Process, one reason I didn't have much trouble was that those RECs didn't need many changes
18:48:44 <fantasai> ... for MQ only 2 changes, for css-contain it was 3, and it doesn't require a script
18:48:50 <fantasai> ... maybe a bit annoying but not that bad
18:48:57 <fantasai> ... so that's part of why I didn't suffer
18:49:05 <fantasai> ... another one is that those changes were non-intrusive
18:49:06 <caribou> caribou has joined #updatable-rec
18:49:20 <fantasai> ... I did hvae one that reworked a list, it would have been complicated to markup in detail
18:49:28 <fantasai> ... but instead I said "this seciton replaced by this other one"
18:49:34 <fantasai> ... so didn't need to diff it, just indicate the replacement
18:49:43 <fantasai> ... If you have many such things piling up, it becomes challenging
18:50:00 <fantasai> ... I'm curious what kinds of situations we get into things that are legitimately REC, but have a very large amount of intrusive changes
18:50:16 <fantasai> ... if you hvae a continuing stream of overlapping changes, it's hard
18:50:20 <fantasai> ... but why is that a REC?
18:50:34 <fantasai> ... obviously might happen to add new features, but other than that how do we get there?
18:50:51 <fantasai> Marcos: when HTlm changed from browsing context to navigable
18:50:54 <fantasai> ... or IDL from void to undefined
18:51:01 <fantasai> ... when a dependency changes, then it's a problem
18:51:12 <fantasai> ... ReSpec can't handle inline changes in the IDL because it's doing validation
18:51:22 <fantasai> florian_irc: you'd have to do at section level
18:51:27 <florian_irc> q+
18:51:27 <fantasai> Marcos: would have to invalidate one of them
18:51:36 <fantasai> Marcos: but working around tooling in that situation, kinda sad
18:51:50 <fantasai> ... if you delete a section, IDL is still there and IDs generated, so tooling is not designed to handle
18:51:53 <fantasai> ... with duplication
18:52:17 <fantasai> Marcos: from your tooling if you have a dfn and it got moved or rewritten?
18:52:32 <fantasai> dom: Wrt how do you get such changes, webRTC got to first REC after decade of effort
18:52:44 <fantasai> ... but you get a lot of corrections from implementations
18:52:52 <fantasai> ... a lot of tooling was about deduplicating IDs
18:53:01 <fantasai> ... again main improvements could be made, this was just making it workable for my docuent
18:53:06 <fantasai> s/docuent/docuent
18:53:08 <fantasai> s/docuent/document
18:53:33 <fantasai> dom: one approach we take is virtually think of, we're making the editorial change of calling this series of steps with name
18:53:33 <nigel> -> https://github.com/w3c/process/issues/402 Thread referenced by Nigel and sideshowbarker
18:53:36 <fantasai> ... and then diff separately
18:53:41 <fantasai> ... but feels a bit hackish
18:53:59 <fantasai> ... how much we can improve depends on fundamental requirement that spec needs to surface the changes such that they can be reviewed
18:54:08 <fantasai> ... that may be where looking for alternatives might be interesting
18:54:53 <fantasai> ... text on /TR right now needs to be clear what's normative or not
18:55:50 <dom> ack gkellogg
18:56:21 <fantasai> fantasai: One of my goals was that people referencing the spec -- everyone who isn't in the process of eidting the spec -- could look at /TR and not need to dig through editor's drafts or a pile of unmerged PRs
18:56:41 <fantasai> gkellogg: We have multiple specs, and need to foster updates for them that aren't in charter atm
18:56:48 <fantasai> ... but WG should get that once it finishes REC process
18:57:02 <fantasai> ... we're marking the specs as being updatable, but most ppl working on specs are more cargo-cultish
18:57:02 <plh> (we don't have tutorials for this because of lack of tooling for updatable-rec)
18:57:12 <fantasai> ... if something is broken in PR helpful
18:57:19 <fantasai> ... fuzzy on some of the mechanism works here
18:57:21 <nigel> +1 to training/documentation being helpful, obviously
18:57:25 <fantasai> ... so config file that references PRs?
18:57:34 <fantasai> ... presumably could figure out by looking at PR
18:57:50 <plh> q+ on training/documentation
18:57:56 <fantasai> ... PR is not merged? is the result of an update done by an unmerged PR which magically updates? or expected to be merged into ED?
18:58:11 <fantasai> dom: what I was presenting was just my tooling, it's not official
18:58:22 <fantasai> ... it's a random JSON file in the WebRTC repo. Maybe someday becomes more than that.
18:58:30 <fantasai> ... And yes, expects fully merged PR
18:58:39 <fantasai> ... principle is that the ED should be easy to read
18:58:52 <fantasai> ... it's only when you generate for REC publication that the diffs are surfaced with the tool
18:59:09 <fantasai> ... but there's no tutorial because right now because the only user of this system is me
18:59:18 <fantasai> ... need help from spec authoring tools to make it more usable, because right now it's just for me in my WG
18:59:24 <fantasai> ... not production-ready
18:59:39 <fantasai> florian_irc: there's a little bit of how to mark up the changes manually, and that's not a tutorial and not the ideal state of the world
18:59:48 <fantasai> gkellogg: nightmare stories about trying to do this
18:59:57 <dom> ack Marcos
19:01:05 <fantasai> Marcos: [shows the markup for ins/del]
19:01:22 <fantasai> gkellogg: that's the manual well, so in the hypothetical future something generates that
19:01:31 <fantasai> Marcos: Florian, to your questiona bout where do you get such massive changes
19:01:45 <fantasai> ... it turned out as we update this algorithm to correct it, it made more sense for us to move a bunch of stuff
19:01:56 <fantasai> ... rewrite all these things that were inlined into the algo to have definitions
19:02:08 <fantasai> ... so part of it was editorial, and some of it was normative, so we ended up with 240-line diff
19:02:13 <nigel> q?
19:02:59 <fantasai> Marcos: when there are changes to the process, would be good if as those changes happen, we could beta-test them
19:03:13 <fantasai> ... test-drive the thing
19:03:31 <fantasai> ... e.g. Tab was also surprised when all this stuff came up
19:03:39 <fantasai> ... and frantic rush to incorporate all this stuff
19:04:04 <fantasai> ... so would be nice to have a better way of coordinating all that
19:04:08 <florian_irc> +1 to better coordination
19:04:18 <fantasai> marcos: wrt marketing side, talkd about having a specific designation
19:04:29 <fantasai> ... we have REC which is gold star; Candidate Recommendation is a bit sad
19:04:38 <fantasai> ... maybe it can have a better name
19:04:46 <florian_irc> q?
19:04:51 <fantasai> ... but if reality is going to be specs in perpetual CR that's sad
19:05:06 <fantasai> ... because e.g. WHATWG have their final state stay final
19:05:55 <fantasai> marcos: can't we deputize people to take care of horizontal review on an ongoing basis, so that they get all the vetting before even landing the PR?
19:06:00 <fantasai> ... then we can have a perpetual REC
19:06:25 <florian_irc> fantasai: but then your REC is not useful because people need to work off a pile of PRs
19:06:32 <fantasai> marcos: it works for me
19:06:47 <fantasai> ... I just have 5-6 people to verify my PRs
19:06:53 <nigel> q?
19:06:59 <dom> ack sideshowbarker
19:06:59 <Zakim> sideshowbarker, you wanted to comment
19:07:38 <fantasai> sideshowbarker: One thing, over last few months, started talking to a number of chairs, contributors, individuals
19:07:46 <fantasai> ... was working with Web Assembly about transition to CR
19:07:50 <fantasai> ... and I didn't know the answers to their quesitons
19:08:07 <fantasai> ... I looked in Process doc, but was confused, never looked at Process before
19:08:16 <fantasai> ... Many people expected me to understnad Process but I didn't
19:08:32 <fantasai> ... These are ppl who spoke with me candidly, they're at odds with their own AC rep about what they should do
19:08:41 <fantasai> ... not on AC Forum or anything either
19:08:52 <fantasai> ... So I wanted to explain the Process to them, so had to figure it out myself.
19:09:06 <fantasai> ... as part of this, I wanted to ask them what do you want? what's the value of a WG compared to CG?
19:09:25 <fantasai> ... some people said, we just want a W3C URL for our spec. They should care about, but what they were saying was they dind't care about RF commitments.
19:09:37 <fantasai> ... that surprised me, because I imagine their org cares even if they don't
19:09:55 <fantasai> ... but some what their company wants is RF commitments
19:10:06 <fantasai> ... and then they want to minimize process, because they want to do the leas tamoutn of work
19:10:10 <fantasai> ... quickly and easily
19:10:16 <fantasai> .. other things they complained about is wide review
19:10:26 <fantasai> s/../sideshowbarker/
19:10:36 <fantasai> ... they think it's time-consuming make-work, inefficient
19:10:50 <fantasai> s/sideshowbarker/sideshowbarker:/
19:10:57 <fantasai> ... wrt updateable RECs was, it's a non-problem for them
19:11:15 <fantasai> ... because all they want is RF commitments, and they can get those in CR, then it's hard for me to even articulate to them what they get out of going to REC
19:11:29 <fantasai> ... I said we had wide review, it's a vlaue; but some people don't value that
19:11:37 <fantasai> ... so we need to help socialize what's the value of that
19:11:41 <dom> q?
19:11:54 <fantasai> ... we have a11y and i18n experts, they'll help you get the work done better -- but not articulating that well
19:12:14 <fantasai> ... part of response was also they don't see the value of AC Review
19:12:23 <fantasai> ... if required to go to REC, or required to get their spec published
19:12:34 <fantasai> ... they don't value that, it's an obstacle rather than adding value
19:12:40 <fantasai> ... what they want to do is auto-publish and maintain their spec
19:12:44 <fantasai> ... i.e. CR Drafts
19:12:53 <fantasai> ... and then some interval get a snapshot for RF commitments
19:13:04 <fantasai> ... so that's the background I'm getting
19:13:31 <fantasai> sideshowbarker: The naming. I go tinto that issue, and I almost regret, because not a positive experience
19:13:46 <fantasai> ... Some weighed into that conversation, but got pushback
19:14:01 <fantasai> ... They are confused by the fact that if we have this thing, where they can auto-publish and maintain their spec and get RF commitments
19:14:14 <fantasai> ... doens't give the right labelling to their target audience
19:14:44 <fantasai> ... Andreas suggested a new name, but we have this issue of naming with Candidate Rec. They don't like either Candidate or Recommendation.
19:14:55 <dom> Zakim, close the queue
19:14:55 <Zakim> ok, dom, the speaker queue is closed
19:15:00 <dom> ack florian_irc
19:15:02 <fantasai> florian_irc: Lot in your feedback, Mike, so won't address all but high-level reaction
19:15:13 <fantasai> ... the things they claim they don't care about, they actually care about
19:15:24 <fantasai> ... the reason why W3C stamp is valuable is because of those things
19:15:43 <fantasai> ... so we should make as painless as we can, but the fact that they don't see the value doesn't mean they don't care about
19:15:56 <fantasai> florian_irc: wrt let's review the PRs and then land them, it's ok if it's one or two, itt's fine
19:16:03 <fantasai> ... but it's hard to see the state of the spec if there's a lot
19:16:12 <fantasai> ... in particular, when some of these PRs are longlived. If 1-7 weeks it's fine
19:16:28 <fantasai> ... but if some PR is open for 3 years becaue waiting for implementations, that's not workable
19:16:47 <fantasai> ... alternative thing where we have a half-baked REC with the changes, we started with that
19:17:07 <fantasai> ... we had CSS2 editors draft, and we had many changes, but some were ready and others were not
19:17:15 <fantasai> ... we did that in a document where not distinguished
19:17:38 <fantasai> ... and we had no point that we had all the things ready at once to publish REC until all done
19:17:54 <plh> q-
19:17:54 <fantasai> ... coudl have held back changes, but then they wouldn't be in the spec for people to see
19:18:00 <fantasai> florian_irc: when doing usual cycle of WD -> CR -> PR -> REC
19:18:08 <fantasai> ... you have criteria you meet in a certainorder
19:18:18 <fantasai> ... but currently the amendments are the same requirements but in a different order
19:18:26 <fantasai> ... that's confusing. We should address
19:18:33 <fantasai> ... I think removing PR will help with that
19:18:41 <fantasai> s/PR/Proposed REC/
19:18:55 <astearns> wonders if merging PRs but being able to divine the state of each change from the PR itself (instead of markup in the spec) could be workable
19:18:56 <fantasai> ... I haven't figured it out yet, but maybe it cna help
19:18:58 <dom> ack plh
19:19:00 <dom> ack fantasai
19:19:11 <dom> fantasai: why am I even on the queue?
19:19:21 <dom> s/why am I even on the queue?/
19:19:43 <dom> ... everyone should be able to look at the TR doc to get the current state of the WG consensus and what they should be implementing
19:19:57 <dom> s/everyone/everyone, including those not in the WG/
19:20:42 <fantasai> florian_irc: If an implementer looks at the spec, and implements it, an then is told you implemented the wrong thing, that's not OK
19:21:20 <gkellogg> gkellogg has joined #updatable-rec
19:21:41 <fantasai> https://lists.w3.org/Archives/Public/spec-prod/
19:21:50 <fantasai> Meeting closed.
19:21:55 <RRSAgent> I'm logging. I don't understand 'make minuts', fantasai.  Try /msg RRSAgent help
19:21:58 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/25-updatable-rec-minutes.html fantasai
19:45:21 <gkellogg> gkellogg has joined #updatable-rec
19:56:02 <caribou> caribou has left #updatable-rec
20:08:03 <gkellogg> gkellogg has joined #updatable-rec
20:10:03 <gkellogg> gkellogg has joined #updatable-rec
20:13:37 <gkellogg> gkellogg has left #updatable-rec
21:40:28 <dom> dom has left #updatable-rec