| 14:02 | <shu> | is there a way to join the meeting without logging in |
| 14:02 | <Jesse> | I joined the call anonymously (no prior log in) |
| 14:03 | <bakkot> | you do not have to use the client |
| 14:04 | <shu> | oh i see, i can just enter any name/email, thanks |
| 14:04 | <bakkot> | if you click the "use on the web" it kind of implies you're signing in, but you just put your name and email and then join regardless of what you put in those boxes |
| 14:04 | <Chris de Almeida> | is there a way to join the meeting without logging in |
| 14:04 | <littledan> | I just gave my name and email address, and then the "join as guest" button un-grayed |
| 14:04 | <littledan> | (done on the native client) |
| 14:07 | <shu> | if you click the "use on the web" it kind of implies you're signing in, but you just put your name and email and then join regardless of what you put in those boxes |
| 14:20 | <littledan> | Slides for this presentation at https://github.com/tc39/agendas/blob/littledan-patch-2/2024/tc39-2024-016.pdf (PR'd to the agenda also) |
| 14:21 | <Michael Ficarra> | ooohh we're bringing WinterCG into Ecma? |
| 14:21 | <littledan> | yep! |
| 14:21 | <ryzokuken> | WinterTC |
| 14:21 | <Michael Ficarra> | I imagine it won't continue to be called WinterCG? |
| 14:22 | <littledan> | More context: https://github.com/wintercg/admin/issues/58 |
| 14:22 | <littledan> | The W3C CG will be the main place for technical development; WinterTC will be more for validation and formal standardization (this mirrors CycloneDX) |
| 14:25 | <nicolo-ribaudo> | Are temp checks an official vote? |
| 14:25 | <littledan> | no |
| 14:25 | <nicolo-ribaudo> | It's weird that voting rules apply to temp checks |
| 14:26 | <littledan> | yes, I agree. I think these Ecma rules only apply directly to official votes, which we do not have. That said, I'm not sure if IEs should be able to block. |
| 14:26 | <ljharb> | they're def not votes |
| 14:26 | <littledan> | calling for consensus on advancement might be thought of as an implicit vote |
| 14:26 | <littledan> | but temperature checks certainly aren't votes |
| 14:26 | <Michael Ficarra> | IEs definitely should not be voting/blocking |
| 14:26 | <ljharb> | IEs not being able to participate in consensus would be a radical change from the way tc39 has always operated, so that'd be something that needs discussion |
| 14:27 | <shu> | IEs should not be able to veto |
| 14:27 | <littledan> | IEs not being able to participate in consensus would be a radical change from the way tc39 has always operated, so that'd be something that needs discussion |
| 14:27 | <littledan> | in the queue |
| 14:27 | <ljharb> | about temp checks sure. but ecma rules aren't really relevant; IEs participate in consensus here, and we'd need an agenda item to get consensus on changing that. |
| 14:31 | <ljharb> | shu: "being an IE" is at the discretion of chairs and ecma, so if that were ever abused it would be pretty easy to shut it down |
| 14:32 | <eemeli> | Does consensus for stage advancement count as a "vote" in ECMA terms? |
| 14:33 | <shu> | imo yes? |
| 14:33 | <nicolo-ribaudo> | I think so |
| 14:33 | <ljharb> | no |
| 14:33 | <shu> | like i don't see why there would be any bylaws if any TC can also just say "actually we don't do that"? |
| 14:33 | <ljharb> | it's consensus. not a vote. |
| 14:33 | <ljharb> | if it was a vote than we wouldn't ask individuals, we'd ask members. |
| 14:33 | <nicolo-ribaudo> | And we informally agree that the champions only "ask for the vote" if there is would be full consensus anyway, so no vote needed |
| 14:34 | <shu> | i strongly disagree |
| 14:34 | <ljharb> | for example, google having 30 delegates would still only get 1 response to a call for consensus. that's not how we operate, or have literally ever operated. |
| 14:34 | <littledan> | there has long been disagreement within the committee about what the policy is. It's good for this to be on the table for discussion. |
| 14:35 | <ljharb> | it's fine to discuss it, and if someone would like to, it'd be great to add an agenda item for it. but making a change here would be dramatic and unprecedented for tc39, and isn't a matter of simply "interpreting bylaws". |
| 14:35 | <eemeli> | It would be Really Good for execom to explicitly comment on our consensus practices. |
| 14:36 | <littledan> | good reminder from @ljharb on GitHub teams, and thank you for your good work on setting up the GitHub teams. I do want to note that we have some inconsistencies between the GitHub and Ecma data (which member organizations have provided to Ecma and are published in the Ecma memento) and we will need to work through these. I believe neither one of these is perfectly up to date, and we will make a lot of progress by reconciling them. |
| 14:36 | <ljharb> | in general, laws serve the people, so if the bylaws conflict with what committees actually do, the bylaws, not us, should change. |
| 14:37 | <littledan> | It would be Really Good for execom to explicitly comment on our consensus practices. |
| 14:39 | <littledan> | in general, laws serve the people, so if the bylaws conflict with what committees actually do, the bylaws, not us, should change. |
| 14:40 | <littledan> | I mean, this is why I got involved in Ecma stuff in the first place, to ensure that we had an IE policy in the first place and that we didn't accidentally kick Babel etc out |
| 14:42 | <eemeli> | littledan: Does "a bit much" mean that there's an expectation for us to change something at some point, or that the divergence from expectations is small enough to ignore? |
| 14:43 | <ljharb> | i mean sure, but opinions that differ from 100% of past history don't change what's actually happened |
| 14:44 | <ljharb> | it's fine to believe IEs shouldn't participate in consensus, for example, but that's only relevant in a discussion about whether to change the fact that they do :-) (which is also fine to have, ofc) |
| 14:50 | <littledan> | littledan: Does "a bit much" mean that there's an expectation for us to change something at some point, or that the divergence from expectations is small enough to ignore? |
| 14:50 | <littledan> | i mean sure, but opinions that differ from 100% of past history don't change what's actually happened |
| 14:51 | <ljharb> | there's no such thing as "block". there's either consensus for something, or not |
| 14:51 | <littledan> | IEs are definitely here to participate actively in all technical discussions, and express strong negative opinions when there's a request for consensus, no doubt about that. If they make a good argument, they won't be the only blocker, so this is probably not a very impactful decision. |
| 15:10 | <Ben> | 402 update slides: https://notes.igalia.com/p/fxx00_k5K#/ |
| 15:14 | <nicolo-ribaudo> | This transcriber wrote "camel cased" as CamelCased |
| 15:14 | <nicolo-ribaudo> | π― |
| 15:19 | <ljharb> | oh no, that's PascalCased tho |
| 15:21 | <dminor> | ptomato: Could you please provide a link to the sovereign tech fund that is funding the test262 work? Or to your slides? |
| 15:22 | <ljharb> | it's Germany |
| 15:22 | <ljharb> | https://www.sovereigntechfund.de |
| 15:22 | <ptomato> | I was about to paste the content of the slide into the notes, will that work? |
| 15:22 | <ljharb> | they also gave nearly a million to the OpenJS Foundation last year |
| 15:22 | <ptomato> | otherwise yes what Jordan said |
| 15:22 | <ljharb> | they're doing what all governments should be doing :-) it's great |
| 15:22 | <dminor> | Great, thank you :) |
| 15:29 | <dminor> | Hypothetical question, would we take money from any sovereign tech fund, or would we consider things like human rights records, etc. before accepting funding? |
| 15:29 | <littledan> | apparently there's also https://nlnet.nl/bluehatsprize/2024 currently seeking nominations |
| 15:31 | <shu> | Hypothetical question, would we take money from any sovereign tech fund, or would we consider things like human rights records, etc. before accepting funding? |
| 15:33 | <dminor> | Well, in that case I guess it's Igalia's decision, but yes, I'm kind of wondering how we as a group would feel about this. |
| 15:33 | <littledan> | There's also https://www.opentech.fund (from the US govt) , specifically https://apply.opentech.fund/foss-sustainability-fund/ |
| 15:34 | <littledan> | Well, in that case I guess it's Igalia's decision, but yes, I'm kind of wondering how we as a group would feel about this. |
| 15:34 | <shu> | i feel like TC39 itself isn't a legal entity to receive funds, so i imagine it's just up to Ecma |
| 15:35 | <Michael Ficarra> | it'd be nice if the CoC update included what actions were taken (if any) instead of just saying "it's been resolved" |
| 15:36 | <shu> | the usual non-profit donation tricks abound, i imagine, with whether you can or cannot earmark donations for specific activities, especially if it's from a government |
| 15:42 | <littledan> | FWIW Ecma is a Swiss "association", not a US 501(c)(3). I think this makes certain things more flexible (IANAL!) |
| 15:42 | <Michael Ficarra> | serious question: is there anyone who goes to the Firefox download page, says "300MB?! No thanks.", and leaves? |
| 15:43 | <Michael Ficarra> | I think by the time you're there, you're downloading Firefox, right? |
| 15:43 | <littledan> | it's sort of a cumulative thing though, right? |
| 15:43 | <littledan> | especially for mobile |
| 15:43 | <shu> | my intuition on almost all size concerns are about mobile, not desktop |
| 15:43 | <Michael Ficarra> | you mean Mozilla wants to save upload bandwidth? |
| 15:43 | <shu> | indeed i don't think people say that to the desktop downloader |
| 15:43 | <nicolo-ribaudo> | serious question: is there anyone who goes to the Firefox download page, says "300MB?! No thanks.", and leaves? |
| 15:43 | <nicolo-ribaudo> | And all phones already have a built-in browser |
| 15:44 | <shu> | also, markets with significantly cheaper hardware |
| 15:44 | <ljharb> | how small is the average phone in those markets these days? |
| 15:44 | <littledan> | I think it's more about download bandwidth |
| 15:45 | <nicolo-ribaudo> | how small is the average phone in those markets these days? |
| 15:48 | <bakkot> | how small is the average phone in those markets these days? |
| 15:48 | <ljharb> | that's what i'd expect |
| 15:48 | <Jesse> | for me it's images/movies, not apps, that take up space |
| 15:49 | <eemeli> | To be picky, Firefox desktop on MacOS is currently 134MB, and on Android it's 88MB. |
| 15:49 | <Michael Ficarra> | yeah I was too lazy to look up the actual number |
| 15:50 | <Michael Ficarra> | here, let me fix it for you: "134MB?! No thanks." |
| 15:51 | <ryzokuken> | for me it's images/movies, not apps, that take up space |
| 15:53 | <Chris de Almeida> | it'd be nice if the CoC update included what actions were taken (if any) instead of just saying "it's been resolved" per the Code of Conduct:
|
| 15:55 | <Michael Ficarra> | telling us what actions were taken (like somebody being banned from a particular forum) is not discussing the issue IMO |
| 15:58 | <littledan> | The CoC committee could refer more public statements to the chair or secretariat for disclosure. Overall I think we have enough experience that statements like, "there was a report, it was handled" don't really make all of TC39 feel more secure about the process. But maybe we should just trust the CoC committee, and even these notifications are unnecessary--confidentiality is really important to preserve. |
| 15:59 | <shu> | yeah i think if you want to be confidential just don't update |
| 15:59 | <shu> | 100% confidential, that is |
| 16:00 | <Chris de Almeida> | depending on the action taken, saying what that action was may have privacy risk |
| 16:00 | <ryzokuken> | there's no harm in evolving our CoC processes in order to better serve delegates and make everyone feel more secure about our working environment here |
| 16:10 | <Chris de Almeida> | it's up to TC39 what the CoC is and how the CoC committee reports back to TC39 and the ExeCom/GA. if folks want to change the CoC, that's fine. it needs to be raised and get consensus at plenary |
| 16:22 | <littledan> | Definitely needs an agenda item to draw a conclusion; this is just some earlier discussion/feedback, which is also valid (like our above discussion about Ecma rules despite this not being a GA meeting). The CoC committee could also be the ones to propose something to plenary, based on this kind of feedback. |
| 16:33 | <Chris de Almeida> | you're absolutely right. I want to be clear it's not a matter the CoC committee can unilaterally decide |
| 16:40 | <littledan> | About blocks: IMO IEs should generally be able to operate equally to all other committee delegates, and the process focus should probably be more on, what can we do in response to someone (anyone) blocking, and whether the committee may still have general consensus (e.g., by establishing that general consensus at a follow-on meeting once we all have more time to consider things). |
| 17:06 | <bakkot> | I don't know that "I would prefer to work with arrays" is... really an answer to "what is the benefit"? |
| 17:13 | <littledan> | yeah I think we kinda settled this with iterator helpers a while ago... I did try to give more space to the iterables vs iterators discussion with inviting Axel in, etc. |
| 17:14 | <shu> | i mean i also to prefer to work with arrays when cache locality matters |
| 17:14 | <shu> | but i don't know if i care about it for joint iteration in particular |
| 17:15 | <shu> | and "caring about cache locality" certainly argues for case-by-case for the operation, not a catch-all |
| 17:15 | <ljharb> | to be clear i'm not arguing for 100% symmetry |
| 17:16 | <Michael Ficarra> | FYI I consider take/drop to be the analogue to slice @nicolo-ribaudo @bakkot |
| 17:16 | <bakkot> | they're certainly similar, just not identical |
| 17:20 | <bakkot> | I would like us to explicitly have a policy that we don't use "this package has many downloads" as a reason to add a feature |
| 17:20 | <bakkot> | "this package has many dependents from different authors", sure |
| 17:21 | <nicolo-ribaudo> | (in this case, the package is a transitive dependency of Jest and yargs) |
| 17:21 | <ljharb> | yeah i was more saying, this is empirical evidence that the original belief is false |
| 17:21 | <ljharb> | (that everybody would prefer an aiife) |
| 17:22 | <Michael Ficarra> | but i don't know if i care about it for joint iteration in particular |
| 17:26 | <shu> | ok |
| 17:26 | <bakkot> | tbc, the closest analogy is new Promise(r => r(foo(args))), not a try-catch |
| 17:26 | <littledan> | We've heard a lot of skepticism on motivation. Maybe we should do a temperature check? |
| 17:27 | <nicolo-ribaudo> | My position is exactly the same |
| 17:28 | <nicolo-ribaudo> | "Not bad, but not convinced that it's useful" |
| 17:29 | <littledan> | Promise.prototype.catch/finally are really different from Promise.try... |
| 17:30 | <shu> | we have spent more time talking about the check than just doing the check |
| 17:31 | <tkopp> | I like the hoisting of a sometimes promised function into a definite promise. It helps decluttering functional chaining. |
| 17:31 | <ptomato> | we have spent more time talking about the check than just doing the check |
| 17:34 | <danielrosenwasser> | Promise.prototype.catch/finally are really different from Promise.try... |
| 17:34 | <nicolo-ribaudo> | Temp polls should have a symmetrical state, going from Strong Positive to Strong Negative |
| 17:36 | <littledan> | I voted "indifferent" based on agreeing with what Nicolo said. The intended meaning is not "abstain" |
| 17:37 | <bakkot> | "very weak negative" is how I intended my "indifferent" |
| 17:37 | <danielrosenwasser> | I assumed "π" was abstain |
| 17:37 | <waldemar> | Indifferent indicates that you had time to consider the issue and vote. |
| 17:38 | <waldemar> | Indifferent has no negative connotations to me. |
| 17:38 | <waldemar> | Without "indifferent" it would be hard to tell if people had a chance to vote. |
| 17:38 | <littledan> | communication is all about relationships and context, and not only absolute meanings of words |
| 17:39 | <littledan> | here, several people explicitly clarified that they specifically meant "very weak negative", so it doesn't really matter if "indifferent" generally has no negative connotations |
| 17:39 | <littledan> | anyway it has Stage 2.7 so this is closed, I think |
| 17:39 | <bakkot> | I guess given that we would not advance a proposal unless at least some people were strongly positive, and that "very weak negative" is "I don't object to advancement", there's not much practical difference between the two |
| 17:40 | <littledan> | in this case, yes |
| 17:40 | <Chris de Almeida> | more of an aside, but we regularly change the semantics of what the temp check options are because they don't always align well with the question |
| 17:40 | <littledan> | I did want to elicit some more positive/strongly positive feedback, which we did get |
| 17:42 | <Michael Ficarra> | just a backslash wouldn't work anyway since we got rid of identity escapes |
| 17:42 | <Michael Ficarra> | so it'd be replacing the first character with an escape sequence for that character, like a hex escape |
| 17:42 | <Michael Ficarra> | if this is even needed, which I don't believe it is |
| 17:44 | <littledan> | Temp polls should have a symmetrical state, going from Strong Positive to Strong Negative |
| 17:44 | <littledan> | and in particular, temperature checks were designed to avoid, well, this kind of vote as a use case, to be honest |
| 17:44 | <nicolo-ribaudo> | I opened https://github.com/bterlson/tcq/pull/67 for now |
| 17:46 | <Michael Ficarra> | strictly more options?! |
| 17:46 | <Michael Ficarra> | please no, please get rid of some options at the same time |
| 17:47 | <nicolo-ribaudo> | Who should take the fall, "Strongly positive" or "Following" |
| 17:47 | <ljharb> | following |
| 17:48 | <ptomato> | following. has anyone ever voted following |
| 17:48 | <Michael Ficarra> | following for sure |
| 17:49 | <littledan> | So "unconvinced" is weakly negative, and "negative" is strongly negative? Should we rename the options to be symmetrical? |
| 17:49 | <Michael Ficarra> | also confused because if you're confused, you should be asking for clarification, not voting! |
| 17:49 | <littledan> | I guess in this case, "unconvinced" being the strongest negative option makes it scary to vote for |
| 17:50 | <littledan> | no, confused is good, we should keep it--it's a big problem if people are confused and afraid to ask! |
| 17:50 | <nicolo-ribaudo> | I think calling it unconvinced is more expressive than "weakly negative" |
| 17:51 | <nicolo-ribaudo> | Or "This temperature check has been worded terribly I don't understand what the options mean in this case" π |
| 17:51 | <littledan> | OK, I'm convinced :) |
| 17:51 | <littledan> | the most important thing is to have something stronger than unconvinced, so that unconvinced becomes less harsh, I think |
| 17:57 | <nicolo-ribaudo> | Ughh I just noticed that I forgot to add slides to one of my topics on the agenda (a status update) -- I'm sorry |
| 17:57 | <Michael Ficarra> | this is enough change in the proposal that, even Wednesday, I don't think I'd be prepared to advance to 2.7 |
| 17:57 | <ljharb> | 100% agreed |
| 17:58 | <ljharb> | maybe with just one of these changes, but with 2 or 3 i'd rather wait |
| 17:58 | <Michael Ficarra> | to be clear, I think they're all good improvements, but I'd want to review it as a whole again |
| 18:00 | <ljharb> | yep, i've unchecked all the signoffs so i know to re-ask |
| 18:00 | <ljharb> | btw for the steno, can we get them to stop double spacing after periods? |
| 18:01 | <Michael Ficarra> | they're also inserting newlines at the page width instead of letting it wrap π |
| 18:02 | <nicolo-ribaudo> | "Can you please set your line width to 100_000_000?" |
| 18:02 | <ljharb> | both of those, yes please |
| 18:03 | <littledan> | we've asked the stenographers to do this before. They should be doing it. I'll call them today. |
| 18:03 | <littledan> | They've fixed this in the past, it's just that not all of them do it |
| 18:25 | <bakkot> | waldemar: On the topic of RegExp escapes, what escaping do you think we ought to use for null bytes? We have \0, but \x00 is plenty readable, and \0 has the complication that you can't use it if the next character is an ASCII digit. My inclination is to use \x00. |
| 18:56 | <Michael Ficarra> | should microwait be called microWait? |
| 18:58 | <bakkot> | should "kilogram" be spelled "kiloGram"? |
| 19:00 | <Michael Ficarra> | if it was a JS API? probably |
| 19:01 | <bakkot> | nooooo |
| 19:01 | <bakkot> | we use camel case when it's two words |
| 19:01 | <bakkot> | but "micro" is a prefix, not a new word |
| 19:01 | <nicolo-ribaudo> | setTimeOut |
| 19:03 | <nicolo-ribaudo> | Feedback about WebEx: much better than zoom |
| 19:04 | <shu> | i liked how it had a light mode |
| 19:04 | <shu> | down with dark mode!! |
| 19:04 | <Michael Ficarra> | much better than I expected, about the same as zoom |
| 19:04 | <ryzokuken> | please qualify better better. |
| 19:04 | <bakkot> | it is literally indistinguishable afacit |
| 19:04 | <nicolo-ribaudo> | In Zoom I always have audio issues |
| 19:04 | <nicolo-ribaudo> | It never works the first time |
| 19:04 | <shu> | is this a zoom problem or is this "year of linux on the desktop" problem |
| 19:04 | <ptomato> | video/screenshare entirely didn't work on firefox for me, so webex is a ποΈ from me |
| 19:05 | <nicolo-ribaudo> | is this a zoom problem or is this "year of linux on the desktop" problem |
| 19:05 | <Michael Ficarra> | it only allowed you to share "apps", not windows, so if I changed which Chrome window was focused, it would share that one instead |
| 19:05 | <ryzokuken> | IMO the web version was nicer than zoom and thus I had no reason to even attempt to use the native (apropos the parens thingie that was weird) and zoom's native version just takes years off my life |
| 19:05 | <nicolo-ribaudo> | video/screenshare entirely didn't work on firefox for me, so webex is a ποΈ from me |
| 19:05 | <nicolo-ribaudo> | IMO the web version was nicer than zoom and thus I had no reason to even attempt to use the native (apropos the parens thingie that was weird) and zoom's native version just takes years off my life |
| 19:05 | <nicolo-ribaudo> | Long live the web |
| 19:06 | <ryzokuken> | IMO the web version was nicer than zoom and thus I had no reason to even attempt to use the native (apropos the parens thingie that was weird) and zoom's native version just takes years off my life |
| 19:06 | <ryzokuken> | like other native video conferencing apps exist, many of them are electron based and still do a vastly better job |
| 20:17 | <ljharb> | mine, from chrome, let me choose which specific chrome tab i wanted to share (zoom does also) |
| 20:30 | <ptomato> | I think that's a chrome/chromium-specific feature |
| 23:10 | <waldemar> | waldemar: On the topic of RegExp escapes, what escaping do you think we ought to use for null bytes? We have \x00 for the reasons you state. |