• full-icu-npm is the full-icu npm module
• full-icu-test is the CITGM test for it.
• icu4c-data-npm is the helper which builds and publishes icu4c data to NPM. This is becoming obsolete whenever unicode-org/full-icu-npm#36 is implemented, because on the ICU side the data is published as seaprate zip files in github https://unicode-org.atlassian.net/browse/ICU-20600

So, this could be a good candidate for a monorepo.

I've got a minor concern here that since @srl295's focus has changed away from these modules and there was no mention of anyone already maintaining it (looking to onboard vs. enabling existing maintainers) that there's a non-trivial chance that we won't be able to maintain these effectively.

🖐️ I could help out with maintaining these packages if you need any.

@bnb out of the gate, if not much action is taken other than to transfer these to the node org – there's definitely a chance we won't be able to maintain them effectively. 💯

A couple thoughts though:

• Before transferring ownership, we should discuss this in full at our next @nodejs/i18n WG meeting with @srl295 and any other active maintainers of these repos in order to better understand the requirements of effectively maintaining them – and if members of node or Unicode are better suited to do this. There's really no other org these are directly related to, so coming to a conclusion on this will be key.
• As mentioned, this request is coming at a time where node's central g11n contributor is shifting focus – and a gap will be felt. So we're going to need to put out a call for participation soon for the @nodejs/i18n-api team regardless, which will require better documentation for new contributor onboarding, etc. @srl295 will be available to guide us as we shift focus on building sustainability for this, so that's very positive. I'm excited to support this effort, and imo having the modules live in this org could be a good forcing function to expand and diversify participation for g11n in node (everything under the same roof). However, if after further discussion the maintainers express that onboarding new contributors through node to help maintain these modules might be less effective than keeping the repos in Unicode and doing something similar there: then we can defer to their judgement and support them as they need it. 👍

Thanks a mil @bnb. 🙏

@srl295 any thoughts?

I've got a minor concern here that since @srl295's focus has changed away from these modules and there was no mention of anyone already maintaining it (looking to onboard vs. enabling existing maintainers) that there's a non-trivial chance that we won't be able to maintain these effectively.

Really great thoughts. However, it's not getting any maintenance by other ICU people. (Historically it started as part of ICU because I was revving the ICU tools, but that's been superseded by other work within Icu.) And the reality is that it is commonly used within the node ecosystem. So, owner wise if it's within node i18n it will be more likely to get any updates.

Icu-tc was supportive of this when discussed last.

Also I'm glad to help onboard anyone/everyone, @ryzokuken (Thanks) or others.

+1 then. I would like to only request that if we do accept that we also have a plan for messaging in the case where we're not able to find active maintainers / the maintainers that start are not able to commit to long-term maintenance.

+1 from me and many thanks to @srl295 for keeping it going thus far

+1 from me and thanks for all of the hard work put in by @srl295