TC39 Delegates on 2022-06-10

04:00	<ljharb>	Temporal is stage 3 but not yet shippable, for example
04:01	<ljharb>	i definitely agree that the time to identify these kinds of risk areas is stage 3 acceptance - i have an open process document PR to that effect
04:58	<Jack Works>	A question, why Temporal not named `Time`?
06:09	<rkirsling>	because it's a DateTime library, not just a Time library :D
06:09	<rkirsling>	er s/library/module/ whatever
06:10	<Kris Kowal>	diem et tempus
06:10	<Ashley Claymore>	er s/library/module/ whatever Namespace?
06:11	<rkirsling>	that too 😅
06:16	<Kris Kowal>	A question, why Temporal not named `Time`? To me, temporal reads as “about time” rather than “time”, so it stretches to cover “date”, “moment”, “duration”, “clock”, “calendar”, “timezone”, “appointment”, and “procrastinate” more easily. Every precedent has been tried and this one’s not the worst.
06:19	<Kris Kowal>	But yes, if we did not tend to conflate Time with wall-clock time by default, Time would be a better name for the namespace.
06:20	<Kris Kowal>	It’s like, what do you call a Test in a test framework?
06:22	<Kris Kowal>	Or, what do you call a Module in a module system? (Trick question, you name nothing Module and burn its page in the dictionary)
06:27	<Ashley Claymore>	“Relating to practical matters” 😆
06:28	<Ashley Claymore>	I like this as, in practice, it will be much nicer than Date
06:29	<rkirsling>	I guess even more importantly, it's that Time sounds like a companion to, and not a replacement for, Date
06:31	<Ashley Claymore>	That’s a really good point, the “marketing message” is a bit easier with a more distinct name
06:32	<Ashley Claymore>	“Use Temporal” rather than “use Time”
07:00	<Rob Palmer>	Reminder: the 19-21 July plenary meeting includes the possibility of in-person attendance in San Francisco at Google's office, but you must register in advance for this. Right now there are 27 remaining places. https://github.com/tc39/Reflector/issues/437
12:24	<littledan>	Temporal is stage 3 but not yet shippable, for example My contention is that this determination is best done unilaterally by champions. Do you agree?
17:49	<ljharb>	My contention is that this determination is best done unilaterally by champions. Do you agree? i think champions should be free to unilaterally decide when they think it's ready, but like all committee decisions, if there's objectors then it needs to be discussed
17:50	<ljharb>	i expect virtually every case to be uncontroversial, ofc
18:16	<littledan>	hmm, I agree that all committee members should be able to bring things up for discussion, but I don't think we'll get consensus on a process change which would require an additional consensus-seeking step which marks "shippability". I was hoping that this could be more like a documentation improvement, process-wise and not even require discussion in a meeting (more like encourage notification but not necessarily synchronized with meetings).
18:19	<littledan>	in general, proposal authors can go about editing their proposals pre-Stage 3 without committee consensus, and even after Stage 3, only normative changes require consensus (whereas this is sort of editorial). Committee consensus (which is the only time it makes sense to talk about "objectors") is only required at stage advancement or consideration of normative PRs (including to Stage 3 proposals)
18:54	<ljharb>	i didn't mean consensus would be required first
18:55	<ljharb>	i'm just saying that if delegates think it's not actually shippable, that needs to be discussed
19:27	<littledan>	right, I agree that any discussions about proposals can be brought up to the committee, whether by the champion or some other delegate
19:31	<littledan>	(I'm not sure how to interpret "needs"--who would this be an obligation on, and how would we judge whether we're in the state of needing that? But any delegate who thinks they have something important to discuss can do so.)