| 00:04 | <ptomato> | it does fit with the idea of TC39 as 'standing athwart history, yelling Stop' which seems to be one of the dominant mental models within committee |
| 00:06 | <ptomato> | (not one that I agree with, to be clear) |
| 00:24 | <shu> | i am not even interested in asking for a broad change currently, just for Temporal |
| 00:25 | <jschoi> | (This is the first time in years I’ve seen “athwart”. It is a great word.) |
| 00:25 | <shu> | i would invite folks with that mental model to contemplate if they would actually yell "stop" to a normative fix you present, ptomato |
| 00:39 | <Kris Kowal> | as a strict constructivist, I don't believe sets are real |
| 00:41 | <Kris Kowal> | Or rather, most of them are not real. Pretty sure there’s proof to that effect. |
| 00:44 | <jschoi> | Sounds pretty complex to me. |
| 00:45 | <shu> | i... |
| 00:53 | <Kris Kowal> | Sounds pretty complex to me. |
| 02:03 | <ljharb> | tbh i think the requirement to present everything to plenary is actually a useful barrier; it means that all the things that get presented end up being obvious/boring |
| 02:04 | <ljharb> | and considering how many times it was brought up by littledan to demote global to stage 2 based on the name change, that nobody's considering Temporal to need demotion is a bit confusing |
| 14:11 | <littledan> | idk maybe that was a mistake... ultimately I am still not really happy about the process global used. I think champions should be more transparent with the committee. |
| 14:11 | <littledan> | so I'm a little wary of using that experience as an example that we should follow |
| 14:13 | <littledan> | in the case of global, the whole proposal was only a name, and the stage 3 status was actively being used by multiple JS implementations/environments as a reason to ship exactly that (even after compat issues were discovered). So demoting was one way to send the signal that this wasn't the final state, though there would've been other ways. |
| 14:15 | <littledan> | The tweaks being made to Temporal are much smaller in proportion to the size of the proposal. It is good that we aren't revisiting names, for example |
| 15:03 | <shu> | yes, i strongly agree the bar for demotion is something like "if it is no longer clear what needs to be implemented" and "if keeping stage 3 means shipping the wrong thing" |
| 15:03 | <shu> | temporal, while noisy, seems like all bugfixes to me, a bunch of which only (realistically) was going to be found after someone started implementing |
| 15:03 | <shu> | so demotion would be the exact wrong thing to do here |
| 15:04 | <shu> | for something of temporal's size, the bugfix noise is pretty unavoidable |
| 15:14 | <littledan> | Procedurally, my understanding that the requirement for demotion, like promotion, is consensus. |
| 15:23 | <shu> | mine as well |
| 15:23 | <littledan> | we achieved that with global, and with static class features, so things were above board, but it's possible to object to demotion, I think |
| 15:25 | <shu> | yeah, i'm explaining the expectation of the bar i'd be judging proposals by if something came up for demotion |
| 15:25 | <littledan> | yeah, I agree with your bar |
| 15:25 | <littledan> | that this is what delegates should keep in mind |
| 15:26 | <littledan> | maybe it's time for a how-we-work PR? |
| 18:42 | <rkirsling> | also Temporal is the size of a new spec unto itself so it's really not fair to compare it to a run-of-the-mill small proposal |
| 19:07 | <justingrant> | rkirsling: that's a really good point! What makes Temporal hard is that the proposal is a family of related types rather than individual types or functions that can be added incrementally and individually. It's hard to imagine any other problem domain being added to the language that would require such a large surface area, with the possible exception of file I/O if that's ever added to the standard library. |
| 19:07 | <ljharb> | i totally agree demotion requires the same consensus advancement does, and that temporal isn't really stage 2 (nor was global at the time), but also neither is/was truly stage 3. i wish we had some kind of stage 3.5 |
| 19:10 | <littledan> | yeah, we talked about something after stage 3 in this room; I think it'd be good to bring that to committee at some point for further discussion. We agreed on a lot of things (e.g., that by default, something is "shippable" when promoted to Stage 3 unless otherwise specified) and we identified a point of disagreement whether the champion can just unilaterally document whether something is "shippable", or whether this is subject to review/consensus/objections by the rest of the committee. |
| 19:21 | <littledan> | Stenography support may be coming to the next plenary! If you get a chance, editing the glossary will help the captioner. https://github.com/tc39/how-we-work/blob/main/terminology.md |
| 19:49 | <shu> | yeah, i'm positive on a stage 3.5 with relatively little oversight |
| 19:49 | <shu> | i.e. a little more formalism than what's happening today which is like a browser saying "hey btw let's not ship this until we iron out this issue" and everyone else nodding |
| 21:21 | <jschoi> | Would Stage 3.5 occur on all proposals or just “special” ones similar to Temporal? |
| 21:22 | <littledan> | The idea is to have a column in the proposals repo which is whether something is "shippable" (or maybe inversely, whether it has open questions which block shipping). In the normal course, the shippable bit is set at the same time as going to Stage 3. All proposals would have this bit, not just ones which are un-shippable. |
| 21:23 | <littledan> | there would be no real contract associated with the shippable bit; it's just a piece of advice from the champion to implementers and everyone else, in my (and Shu's, maybe) vision of how this works |
| 21:24 | <shu> | there's like, a social contract, in the world |
| 21:24 | <shu> | there's no formal contract in committee |
| 21:24 | <littledan> | right |
| 21:24 | <littledan> | brb preparing a docusign |
| 21:24 | <littledan> | of the social contract |
| 21:25 | <shu> | can you imagine, changing consensus process straight to docusign |
| 21:25 | <shu> | 45 counterparties |
| 21:25 | <jschoi> | Would tweaks be needed to the current definition of Stage 3 saying, “The solution is complete and no further work is possible without implementation experience, significant usage and external feedback”? |
| 21:26 | <littledan> | I wasn't picturing any stage process definition tweaks as part of this |
| 21:26 | <littledan> | I think we could clarify the process wording but that's a big separate thing |
| 21:27 | <jschoi> | I suppose the difference between “the solution is complete and [needs] implementation experience” (Stage 3 without the “shippable” checkmark) and “this is ready for serious implementation” (Stage 3 with the “shippable” checkmark) seems a bit subtle. |
| 21:27 | <jschoi> | I’m imagining what it means in general to be at Stage 3 but to not have the shippable checkmark. |
| 21:27 | <littledan> | we've had way too many arguments about this; I don't want to discuss it right now |
| 21:27 | <littledan> | sorry |
| 21:27 | <jschoi> | Ah, okay, sounds good; don’t let me open the Pandora box. |
| 21:30 | <littledan> | I documented what makes sense to do at each stage in https://github.com/tc39/how-we-work/blob/main/champion.md#moving-through-the-stages-in-committee |
| 21:31 | <littledan> | I think we should move towards pointing people to how-we-work more frequently, and the formal process document doesn't need to be how we explain the process in practice to people all the time (since it just leaves so many things out which are important to understand) |
| 21:31 | <littledan> | it's too hard to maintain how-to documentation in a consensus-seeking way |
| 21:40 | <rkirsling> | The idea is to have a column in the proposals repo which is whether something is "shippable" (or maybe inversely, whether it has open questions which block shipping). In the normal course, the shippable bit is set at the same time as going to Stage 3. All proposals would have this bit, not just ones which are un-shippable. |
| 21:49 | <shu> | i'm most excited about how i can apply my newly found, most likely incorrect knowledge of contract law thanks to Elon's antics to tc39 |
| 21:51 | <littledan> | wait, is our alternate copyright policy not accompanied by a matching alternative patent policy saying the same thing but for patents? |
| 21:51 | <littledan> | maybe it's not possible to do that, I dunno |
| 21:52 | <shu> | i did not know there was an analogue for patents |
| 21:57 | <littledan> | ah probably it's not important. Both the Ecma and WHATWG policy limits the patent grant to current and future implementations of the standard (which might imply not forks). Probably broadening it would require bringing in lawyers and isn't necessary in practice |
| 21:58 | <littledan> | sorry for the noise |
| 21:58 | <rkirsling> | i'm most excited about how i can apply my newly found, most likely incorrect knowledge of contract law thanks to Elon's antics to tc39 |
| 21:59 | <rkirsling> | #longrangedependencyproblems |
| 22:36 | <rkirsling> | does anybody else find terminology.md hard to read due to skipping second-level headings |
| 22:36 | <rkirsling> | er |
| 22:36 | <rkirsling> | I mean https://github.com/tc39/how-we-work/blob/main/terminology.md of course |
| 22:37 | <rkirsling> | third-level headings are not prominent enough and would require <hr>s for delineation...or y'know, we could just use second-level headings |
| 22:42 | <rkirsling> | (I wonder if GH's stylesheet changed somewhere along the line; I don't remember being so bothered when editing this document in the past) |
| 23:19 | <rkirsling> | https://github.com/tc39/how-we-work/pull/109 |
| 23:37 | <shu> | reviewing temporal patches is just like |
| 23:37 | <shu> | date time handling is so cursed |
| 23:50 | <jschoi> | This champion.md document is great. To be honest…I had never seen it before. I don’t know why; I feel like I should have noticed it when I looked through how-we-work…And, yes, I had always relied on the process document as my primary reference on what to do at each stage. |