Hey @marc0olo, I noticed that this documentation has disappeared
There used to be clear documentation that explained that an SNS can be deployed via the launchpad (requiring an NNS proposal) or that it can be deployed in a permissionless way given that the framework is open source. The closest there is to that right now is the test flight mainnet launch docs, but this describes mock canisters so isn’t really the same.
Can I ask if the ‘option 2’ path was removed from documentation on purpose? If not can it be salvaged and reinstated somewhere?
I think it’s important for it to be clear to people that launching and SNS via the launchpad is just one way of doing it (the permissioned way). It’s also fully supported to launch an SNS in a permisionless way and that may suit a lot of use cases better than a permissioned launch
Ok first I put on my robe and wizard hat, so you know I’m being serious.
Has there even been an SNS launched not via the launchpad?
Are you planning to launch your SNS without the launchpad?
I can’t imagine why anybody would vote against your SNS. Why not simply submit a proposal?
It’s not very expensive you know it’s only
I’m sure you got that lyin’ around, mate.
Yeah, any SNS I launch will have a twin that’s not launched via the launchpad. That will be an acceptance instance on which all SNS upgrades are tested before being deployed to the production instance (prod instance being the one that was launched via the launchpad).
It also means that proposed SNS versions (not yet blessed) can be manually deployed to acceptance and tested before the NNS has even adopted/blessed it (which also means the proposal can be rejected if issues are detected in acceptance).
As a side note, it’s extremely weird that this isn’t standard practice for all SNSs. This is basically how professional software development is done.
Why so serious, mate?
Cat got your tongue?
I think what he meant to say is…
Good luck with your SNS 
I had a bit a dilemma on this and dropped it during the dfx cleanup if I remember correctly. All of this is currently in maintenance mode, so I need to doublecheck again if we can provide a good guide for this around our new toolchain.
Can you do me a favor and look in the archived portal repo for the content you’d want to get recovered? That would be nice, thanks! 
Hey @marc0olo, this archive doesn’t look like the docs that I recall (and doesn’t contain the ‘Option 2’ flow for SNS deployments). I recall that DFINITY had docs in numerous places, like the developer journey, and maybe also a separate wiki with docs.
Is there anywhere else this documentation may have been archived? Perhaps a prior version of the docs that existed before the version that’s recorded in that archive repo?
if it was tutorials or anything shown on the old docs/homepage it should be in the history of the archived portal. otherwise it was probably some external documentation or some very very old independent repository, which I don’t think is the case for what you ask for 
can you check the portal git history?
Thanks, I’ve found it
portal/docs/developer-docs/integrations/sns/sns-intro.md at dd8129fbacd948f965bcbd1f4b55e4f5e965126c · dfinity/portal
- Self-deploy a DAO by reusing the publicly available SNS code and manually upgrade it. A developer or a community can choose to deploy the SNS code, which is open source, on a normal application subnet. They can then choose to follow the same SNS versions than system-provided SNSs follow or they can choose to deviate from this path. In this option, the DAO community has to be more active in implementing, testing and approving code versions.
I think this needs to be explicit in the documentation still (even though you could argue that it’s implicit). The distinction between ‘permissioned’ and ‘permissionless’ SNSs could actually be made more explicitly I think.
Is there any appetite for getting this back into the current SNS documentation?