| 18:59 | <Kris Kowal> | We conveniently forgot to record a transcript for the module harmony meeting. I would encourage participants to instead write down your key take-ways in the minutes. |
| 19:02 | <nicolo-ribaudo> | Have we already discussed about just recording the meeting, like we do for SES? |
| 19:09 | <Kris Kowal> | I of course believe that’s a better system, but when this last came up, being under the umbrella of ECMA, the same constraints apply as plenary. But, discovering whether those constraints still apply is difficult. |
| 19:11 | <nicolo-ribaudo> | I remember we recorded some parts (presentations?) of some plenaries after making sure that everyone in the meeting was ok with it, so I'd expect the same rule to apply |
| 19:14 | <Kris Kowal> | That’d be good by me. |
| 20:54 | <Mathieu Hofman> | I had a transcription tool running: https://docs.google.com/document/d/16Wh6xh3b1li3O1xbVL0gPYdCD5OXLLH2QAmQtxXpzqA/edit |
| 21:01 | <Kris Kowal> | yulia: Thanks for the ref to C4; I’ll give it a read. |
| 23:05 | <Kris Kowal> | Oh, resolutions from today’s meeting seemed to include “Carve out a Module Harmony Layers repository”. That sounds to me like a clone of tc39/proposal-compartments, plus layer files for expressions, declarations, and import reflection, then additional documents to contemplate intersection semantics in various ways. |
| 23:06 | <Kris Kowal> | Then presumably I turn tc39/proposal-compartments back into its former self, and eject the layer-0 spec text and explainer into tc39/proposal-module-class and tc39/proposal-module-source-class. |
| 23:07 | <Kris Kowal> | Then eject explainers for would-be tc39/proposal-module-parse (binding reflection), tc39/proposal-evaluators, tc39/proposal-module-source-protocols. |
| 23:08 | <Kris Kowal> | Tentatively, tc39/module-harmony, unless yulia would like to establish a precedent for a layer explainer repository naming convention. |
| 23:13 | <littledan> | tc39/epic-module-harmony ? |
| 23:15 | <guybedford> | do you think of module and module source as potential separate new layers Kris Kowal? |
| 23:15 | <guybedford> | or perhaps we just all get behind module expressions for this progression? |
| 23:20 | <Kris Kowal> | tc39/epic-module-harmony ? tc39/eda-, tc39/saga-, tc39/veda-, and tc39/book-, but I suspect that Epic is more likely to convey the right impression. |
| 23:21 | <Kris Kowal> | do you think of module and module source as potential separate new layers Kris Kowal? |
| 23:23 | <Kris Kowal> | I like the idea of cutting features finely for reasons unrelated to bundling or unpacking proposals. Whether that means separate proposals or not is less my concern, unless they have to be separated if Module can advance but ModuleSource cannot. But again, we resolved that would be premature at this stage. |
| 23:25 | <guybedford> | I would prefer we structure in a way that fits the TC39 process though I think |
| 23:25 | <Kris Kowal> | Describing them as separate features in the Epic will allow me to draw up a couple tables, with features along one axis, motivating use cases along the other axis, and clear distinctions between necessary, sufficient, and ergonomic for various combinations of features. |
| 23:26 | <guybedford> | a critical path diagram for stage progressions... |
| 23:26 | <Kris Kowal> | Very much in favor of packing proposals around TC39 process. |
| 23:28 | <Kris Kowal> | And to that end, I think it makes sense for TC39 to evaluate each of the layers as separate proposals. I’m also happy with the restraint folks here have shown, generally trying to get related proposals to similar stages of advancement together. |