docs(cloning): add brief and hld draft

docs/download-upload-clone/brief.md

@@ -0,0 +1,27 @@
+# Cloning Marxan Cloud projects and scenarios
+This document describes the current high-level overview of the Marxan Cloud platform user features related to cloning of projects of scenarios. It is a working document, meant to gather feedback on the requirements before moving on to high level design and detailed implementation plan.
+
+## Aim
+
+Users should be able to clone Marxan Cloud projects for a range of purposes:
+- A user may see a community project (i.e. those that can be browsed without 
+logging in to the platform) and wish to create a copy within their own account, to study it and modify their own copy
+- A student being trained on Marxan may need to clone an existing project (whether public, from the community section, or a private project to which they have been given access by the project owner), in order to study the project and learn how to set up and run Marxan on the project
+- A user may need to download one of their projects, in order to archive a copy that can be later imported into a different Marxan Cloud instance
+- A user may need to set up a local instance of the open source Marxan Cloud platform, importing into it a copy of one or more projects previously downloaded from the flagship Marxan Cloud instance
+
+
+Users should likewise be able to clone Marxan Cloud scenarios (within the same project):
+- Users may wish to undertake a new analysis by changing parameters of an existing scenario, while keeping the original (cloned) scenario intact, so that they can later
+
+In all these use cases, the core operation being described is that of cloning a project or a scenario: this may be done within the platform itself by clicking on a “Clone project” or “Clone scenario” button, or (in the case of projects) as a two-step process, first downloading an archive file containing all the data needed to successively upload the same project to the same or another Marxan Cloud instance, and secondly actually importing the archive.
+
+
+The ability to download and upload an individual scenario may not provide significant value to users, as this would make sense only within a specific project: a scenario downloaded from a project cannot be uploaded within a different project, even if the source and destination projects share exact same planning grid, because of data constraints that would pose significant implementation challenges. Cloning the parent project (which would include all its scenarios) may be all that users need in this case.
+
+Additionally, as a related use case which should nevertheless be significantly different from a requirements and implementation point of view:
+Some users may have Marxan input (.dat) files, planning unit shapefiles and features shapefiles from analyses they may have run through qgis or other tools on their workstation, and may wish to upload these “legacy” projects to a Marxan Cloud instance
+
+
+Cloning of projects
+This operation can be seen, essentially, as a way to create an exact replica of an existing project.

docs/download-upload-clone/high-level-design.md

@@ -0,0 +1,38 @@
+# High Level Design
+
+* exporting a project exports its underlying scenarios
+* scenarios are only exported when the marxan-run took place and its results 
+  are available
+* each scenario should include:
+  * input folder
+  * output folder
+  * grid setup (custom, if present)
+  * <....>
+* existing, pre-defined resources declared below should get unique identifier 
+  which should 
+  be shared across possible instances of MarxanCloud (Database)
+  * GADM boundary data (countries etc.)
+  * WDPA areas
+  * species data (geo.features_data, geo.feature_properties_kv, api.features)
+  * <.....>
+* each of the resource above should consider if it is allowed to be used 
+  (license issues). In case it cannot be used during export, system should ..
+  <......>
+* existing data converted from shapefiles should be converted back to 
+  shapefile format:
+  * cost surface
+  * ....
+* each export is a zip file
+* each export includes information about its current version
+  * in particular, it may also include what was exported, when, by whom etc...
+
+# To be declared 
+
+Things that still need some spike/analysis/decision. As they may not be 
+straightforward, we should consider writing down all pros/cons of all 
+possible solutions that team can come up with, finally making a decision and 
+describing why given solution was picked (and others were discarded).
+
+* existing shapes/data that came from `shapefile` - should it be converted 
+  "back" by the system, or should be store the original uploaded 
+  `shapefiles` and keep their reference?