First thing I would mention is that suffixing with -snap is an anti-pattern. I recommend you publish your snap package under neovim or nvim. Other than that, there is precedent with vscode being classic confined, though an argument in either direction (classic vs strict) can be made for vim/neovim.
To add, namespaces are limited because you can not publish under a team name. Moreover, the shared identity system between the snapstore and launchpad does not help availability.
I suggested neovim-snap for the account name, not for the snap name.(EDIT: which is exactly what you did - use the neovim-snap account to register the neovim snap which is OK. Apologies for the hasty reply! ) @lucyllewy then it looks like the name of both the account and the snap are correct, right?
No worries, I’m just hoping we can get this moving along. It took a lot work and convincing to get the neovim team aboard, so I would hate to have to go through the process all over again.
To clarify yes the package name is nvim and the account is neovim-snap.
I think there is already precedent with many editors, and not just vs code.
If it helps, I’d be OK with granting neovim classic; like you said, it’s expected for such an editor to have access to the entire filesystem and there is good level of precedent for that kind of usage. +1. Note, however, that classic requests aren’t really done by reviewer vote, but by a process involving vetting from @advocacy and review of requirements by @jdstrand (ideally poking them both here would get some attention so we can move toward having the awesome neovim as a classic snap).
@alexmurray@advocacy How long does the vetting take and how do we get started, I would have thought someone would have contact myself or the nvim team by now?
The @advocacy team will post here when they have finished the process. Please note that it can take some time initially to go all the way through the process, but once done, your uploads should pass automated review and you’ll be in full control of your publication process.