Process re forking a spec

[guybedford]

I've been encouraged to create a fork of the Import Maps spec given the feedback on the PR in WICG/import-maps#210.

Per the charter this seems to be an encouraged process, yet there doesn't seem to be much info on the practical process. I would like to request some guidance on what is the proper way to manage this fork, with the goal to build interest and community around the new features and the intent to re-coordinate eventually.

Many thanks!

[marcoscaceres]

Hi @guybedford, is the intention of the fork to just hold the reference implementation? I see you are also updating spec text (as good thing!), so I'm a bit unsure of the value of forking. I guess the underlying questions is, what are you (or others) trying to achieve? If the "depcache" stuff is really contentious, and needs more implementer buy in, then it can either sit as a pull request, or indeed: it should fork.

I agree it will be a mess though - unless you are wanting to demo the feature (I don't know what "depcache" is/does - just providing general guidance). Keeping it as pull request is simplest.

Let me know what you think - and specially we need to know what you want to achieve and we can try to help out!

[guybedford]

Thanks @marcoscaceres for the feedback here. The intention is to get support for the depcache spec to be implemented in browsers as a new feature that is critical for using import maps in optimized production workflows.

Forking would be the simplest conceptual model, but if that's seen as messy we could go the extension route, and carefully indicate how it can integrate into import maps, it would be a little more intricate, but could still work.

I was under the impression from the charter that the fork model was encouraged for building out new features for re-merging, but if this extension model is preferable then I can write it up as a proposal like this too.

[marcoscaceres]

Ok, closing the loop on this, and having read the other discussion, it seems that forking might actually be the way to go. I normally would not recommend that, but I think Domenic makes a compelling case for forking in this case. @WICG/chairs, additional input welcome re: WICG/import-maps#210.

[yoavweiss]

Forking SGTM.

I think figuring out a way to efficiently download and execute modules is critical, even if I haven't dove into the specific proposal here to see if it fits the bill.

It seems like once import-maps is actually standardized, it might be good to "unfork" and create extensibility hooks that will enable this work to build on top of them. But in the immediate forking with the intent to do that or merge seems like the way to go.

[marcoscaceres]

Closing as answered.