transfer of dynamic-modules-proposal repo into nodejs organization

[guybedford]

In the process of working on the Dynamic Modules specification at TC39, it has been deemed that like Web Assembly, the best home for a spec dedicated to Node concerns around modules should be the NodeJS organization.

We are working on some layering and editorial changes to make Dynamic Modules more easily implemented as a separate specification on top of ECMA262, so it will be even simpler/shorter than the existing spec text at https://guybedford.github.io/proposal-dynamic-modules/.

This proposal is part of the work of the modules working group, and as such ownership should be shared as this work continues to progress. We are currently in the process of collaborating on implementation.

[ljharb]

ES proposals are required to live in the TC39 organization at stage 1 and higher; so I’m not sure it’s worth the bookkeeping overhead to move or create a proposal repo into the node org.

[ljharb]

Ah, i misunderstood; you’re talking about a layered sped - then that makes sense :-) hiding my own comments.

[guybedford]

@ljharb the stage 1 TC39 proposal is being withdrawn.

[guybedford]

Ah, sure, no problem!

[bnb]

No issue from my POV. That said, would love to get more context on the decision from TC-39 if at all possible 😄

[Fishrock123]

Shouldn't this be brought up to the modules team, and/or the spec collaboration team, instead of Admin?

[ljharb]

@bnb https://github.com/tc39/tc39-notes/blob/096b8af38c4b4b9684b09692a70938d49b5451a7/es9/2018-07/july-25.md#dynamic-modules

[MylesBorins]

Would also like some clarity as to why this should be a separate repo as opposed to a discussion in in modules or open-standards.

To be clear, not objecting, would just like more clarity

[bmeck]

@MylesBorins probably as a place to put the work and create a specification I would imagine. A discussion thread is hard to manage if we have to deal with PRs and discussing of specific semantics of a document such as seems to be wanting to be produced here. I don't think such a spec text itself would be apt to live in either the modules or open-standards repository much like how proposals to other standards bodies generally have their own repositories.

[MylesBorins]

Ah, I missed that the repo was initially in guy bedfords GitHub.

+1 to transfer it here. I think it would make sense to include a note or pointer from the open standards repo for discoverability

[guybedford]

Shouldn't this be brought up to the modules team, and/or the spec collaboration team, instead of Admin?

@Fishrock123 this is more about the spec work itself needing a home repository for its development. Further discussion with the modules team / spec collaboration team can certainly happen as things develop.

I think it would make sense to include a note or pointer from the open standards repo for discoverability

Sure!

[joyeecheung]

Not exactly specific to this request, but I personally prefer to transfer an existing repo with something concrete created beforehand instead of creating a new repo from scratch in this organization, unless the repo only serves as a place for discussions and there isn't anything of substance in the commit history. Mostly because it's unnecessary to wait for the request to go through before jumping into the work, it also gives us a chance to take a better look at the idea before making it semi-official.

[guybedford]

@joyeecheung the existing repo is at https://github.com/guybedford/proposal-dynamic-modules, including spec text.

[guybedford]

Any suggestions for moving this forward?