| 00:06 | <littledan> | Was the conclusion for SuppressedError cause to simply ignore the options bag, not eagerly check it and, like, throw a worse error if the cause is given? |
| 00:17 | <littledan> | What do people think about putting in a slightly more complete summary in the conclusion for topics in the notes? The idea would be to include a summary of the discussion, not just the points where we reached consensus. I don't see many of these summaries, though. This was a suggestion from several parties, to ensure that our conversations are more accessible. |
| 00:19 | <Michael Ficarra> | I don't think we should summarise the notes within the notes |
| 00:19 | <Michael Ficarra> | if you want to make a summary, keep it separate from the notes |
| 00:20 | <Michael Ficarra> | when I look at the conclusion, I am looking for a clearly spelled out, short description of actions or opinions that we have agreed upon |
| 00:34 | <rbuckton> | Was the conclusion for SuppressedError cause to simply ignore the options bag, not eagerly check it and, like, throw a worse error if the cause is given? |
| 02:17 | <littledan> | OK I have tried to describe this in the conclusion; reviews/edits welcome |
| 02:19 | <littledan> | if you want to make a summary, keep it separate from the notes |
| 02:20 | <littledan> | I was thinking that some kind of Google doc is a better way to do this than, say, some facilitator badgers each champion to write a summary and then concatenates them, because this allows us all to edit the summaries for accuracy |
| 02:33 | <Michael Ficarra> | littledan: someone from the community can do it? |
| 02:34 | <Michael Ficarra> | the raw info is all there in the notes |
| 03:03 | <ljharb> | I don't think we should summarise the notes within the notes |
| 03:55 | <littledan> | littledan: someone from the community can do it? |
| 07:39 | <Rob Palmer> | I would suggest we task the presenter with populating the summary inside the notes doc, next to the conclusion. Google Docs already supports assigning inline issues. On publishing, these can be extracted to a separate file called summary.md |
| 07:40 | <Rob Palmer> | This spreads the workload and provides Champion-assured quality. |
| 08:25 | <Rob Palmer> | Reminder: Nominations for TC39 Chair Group are due by 13 February. The two position available are Chair and Facilitator as described here. |
| 16:34 | <shu> | wait |
| 16:34 | <shu> | you know what we didn't do last plenary |
| 16:34 | <shu> | figure out new name for group |
| 18:16 | <ljharb> | oof, that's right. Justin Ridgewell can we make sure that's on the march agenda? |
| 19:13 | <Justin Ridgewell> | Yah, ran out of time before this meeting to work on it |
| 21:59 | <bakkot> | can we make Array.prototype[Symbol.iterator] non-writable, do you think |
| 21:59 | <bakkot> | in an exotic way so as to not trigger the override mistake |
| 22:00 | <bakkot> | and also the methods on ArrayIteratorPrototype |
| 22:01 | <bakkot> | this would be a commitment to never changing its behavior because such a change could never be polyfilled if it were non-writable, but that commitment seems worth making anyway |
| 22:02 | <ljharb> | nonwritable is fine if it's configurable |
| 22:03 | <ljharb> | or you want it to be exotically nonconfigurable also |
| 22:52 | <bakkot> | nonconfigurable also |
| 22:52 | <bakkot> | specifically I want people not to be able to mess with it |
| 22:52 | <bakkot> | so for (let item of [0, 1, 2]) becomes reliable |