re-enable issues tab on ecmascript-modules

[devsnek]

I think people should report bugs and such with the concrete implementation in the repo where the concrete implementation resides. Is anyone opposed to re-enabling the issues tab on the ecmascript-modules repo?

[MylesBorins]

We already have this repo... is there a distinction between opening an issue here and on ecmascript-modules?

[devsnek]

@MylesBorins for us i would say the only thing is organization. in my head its easier to keep track of things as like "issues with our plans and movement" vs "technical issues with code"

it would also be less confusing for people who aren't part of this org, just trying to report issues they find with the implementation.

[MylesBorins]

@devsnek if people outside this group are not going to be using the implementation in ecmascript-modules wouldn't it make more sense for their issues to be opened upstream on nodejs/node?

[hybrist]

I can see where @devsnek is coming from. My biggest concern would be to keep track of the status of deeply technical issues as the implementation evolves. There's still the potential for some fundamental refactoring in the future. I'm -0 because having a 100% clear location to track everything (these issues) has merit in my eyes. Maybe a label is enough for now?

[GeoffreyBooth]

In developing CoffeeScript 2 we had a “discuss” repo for planning and discussing features and that kind of thing, and the main CoffeeScript repo for actual development; and bugs were reported against the latter. I found it useful to have the two repos.

I think @devsnek’s suggestion makes sense, especially if we make it clear what the other repo’s issues are for, e.g. bugs with that implementation (but not general discussion or feature design/planning).

[SMotaal]

Can I put some context here for @jkrems and @GeoffreyBooth because you may have not seen node/#23783 specifically this and the following comments.

We are running into a potential perspectives problem. For someone with an issues to file, the more repos they need to deal with, the harder it is for them to file an issue. It is not easy to figure out "ecmascript-modules" versus "modules" versus "node" let alone needing to actually understand the process of getting their own concerns through clearly.

It falls on us to make sure that we receive the right feedback, because every attempt, even if filed in the wrong repo (which sadly some projects look down upon) is hard to see from the perspective of someone not familiar with each projects ad-hoc structure.

[ljharb]

Then it sounds like the solution is to rename the fork repo to more clearly indicate what it is?

[SMotaal]

@ljharb what did you have in mind?

[ljharb]

“experimental-ecmascript-modules-fork” or something else super verbose?

[GeoffreyBooth]

“experimental-ecmascript-modules-new-implementation”?

[ljharb]

That implies it's definitely the new implementation, which isn't necessarily the case.

[targos]

We have setup a daily CI job that automatically updates the master and modules-lkgr branches: https://ci.nodejs.org/view/All/job/node-update-ecmascript-modules/

In case of failure, it can send an email to a list of individuals. I put @MylesBorins and my address. Anyone else would like to be notified?

[guybedford]

Amazing work @targos! Please add me as well.