3 ms·
> but in the future, we'd likely entertain requests to reassign ownership of scopes for the benefit of the broader user community (as in the case of a brand own
by diggan 3y ago
> but in the future, we'd likely entertain requests to reassign ownership of scopes for the benefit of the broader user community (as in the case of a brand owner requesting ownership of their brand name).
So you're basically committing to repeating the Kik drama? For reference: https://en.wikipedia.org/wiki/Kik_Messenger#Open-source_module_name https://en.wikipedia.org/wiki/Kik_Messenger#Open-source_modu...
It would be great to find a way of structuring these registries/repositories in a way so there wouldn't be any name collisions, and also avoid the built-in support for companies to take names away from individuals.
- kwhinnery 3y agoThankfully JSR won't be capable of a left-pad situation where packages can be unpublished - published packages are immutable[1]. As for the potential for disagreements over whether or not a scope should be transferred, that is a big reason why we want to figure out community involvement in governance sooner rather than later. We are gathering potential volunteers who want to discuss becoming a community moderator - if anyone would be potentially interested, they can sign up to join that conversation[2]. [1] https://jsr.io/docs/immutability https://jsr.io/docs/immutability [2] https://jsr.io/go/moderator https://jsr.io/go/moderator
- int_19h 3y agoThere are only two ways to do it: 1. Use UUIDs. 2. Use some pre-existing centralized name registry (e.g. domain names). I don't know why the JS ecosystem is so resistant to either solution. Both are proven options (#1 used by COM, #2 used by Java). They do mean longer package names, but surely that's a small price to pay for a resilient future-proof solution? And besides, who really cares about long dependency names and why?