Moisey - Hat tip definitely due, you've been nothing short of responsive about the concerns raised and I can completely understand what led you down this train of thought, although I continue to think it presents an unwelcome surprise to customers thinking about their data security.
Destroyed should mean destroyed and if the outcome is a UX/UI change to remove the 'Scrub Data' (making it default) box and replace with a 'Temporary Snapshot' box (along with accompanying tooltip for explanation) then I think that would be a perfectly great way to assuage my concerns, and a positive development to the DigitalOcean platform.
Obviously there remains a question of how best to tackle this from an API perspective, perhaps you can consider adding a new parameter to /droplets/:id/destroy along the lines of 'temporary_snapshot' (bool) or similar, with a well-documented default behaviour if not passed in.
Agreed, this highlights a larger issue that we've been dealing with as we've grown to over 100,000 customers and the platform has evolved.
When you have a singular product with a very narrow focus, say Instagram, it allows you to really strip away everything besides the core functionality.
When building a platform often you start off with something simple and elegant and as the number of customers grow you quickly begin to realize that as a platform you need to provide more customizability than first intended.
With that in mind we've been working with our customer support team to understand what are the most frequently asked questions and began to automate that directly into the support system as well as provide a more relevant and up to date help guide for the platform. Both inside the control panel directly but also searchable.
Of course one of the thoughts was to make all of the help documentation public on github and then also field requests from the community to help rewrite any documentation that wasn't clear.
Sometimes when you are engineering a product you take for granted all of the knowledge that you have and something that is obvious is entirely missed.
So that would be the idea behind asking our community to help us update the documentation since they come in with fresh eyes and can spot things that we can't see because for us it's been a continuous spectrum of development rather than something that we just walked into at some point in time.
You mentioned in a comment above an occurrence where someone's DO account was compromised leading to many droplets being trashed but that the account holder was able to recover because of the waiting period. If you add a flag to bypass the temporary snapshot would not this mean the hacker could have succeeded in their attempt to wipe out all the droplets?
I actually prefer the enforced cooling off period for destroying droplets. (As long as the UI/API docs are cleaned up a little to communicate it better.)
Replacing one checkbox with another is not solution, since it will remain optional for customer and thus can easily be missed when submitting the form. For such sensitive topic there must be explicit confirmation of user intents.
Destroyed should mean destroyed and if the outcome is a UX/UI change to remove the 'Scrub Data' (making it default) box and replace with a 'Temporary Snapshot' box (along with accompanying tooltip for explanation) then I think that would be a perfectly great way to assuage my concerns, and a positive development to the DigitalOcean platform.
Obviously there remains a question of how best to tackle this from an API perspective, perhaps you can consider adding a new parameter to /droplets/:id/destroy along the lines of 'temporary_snapshot' (bool) or similar, with a well-documented default behaviour if not passed in.