Provide URL input with import functionality. Create a .zip of what is available from the URL. Users must paste the URL of the repo’s landing page (easily found in their browser’s address bar). If they paste the default landing page, they get the default branch up to the latest commit. If desired, they can use the URL for a specific branch, release, or commit.
System uses "repoName-branchName" or repoName-releaseNameNumber as ZIP name. User can edit the name.
Users could add more than one file to the dataset. If this happens, the concept of archiving a GitHub repository as a dataset would be broken.
Messaging/tool tip stating if they want to maintain their repository as a dataset, they should not add any other files.
If a user adds one or more files to the dataset, having a DOI that refers only to the GitHub repository would rely on file-level DOIs, and not all installations have file-level DOIs enabled.
User can add metadata to the Description field (as now – no change).
The repo URL is saved in the database and displayed on the page.
Edit the ZIP just like any other file deposited into a dataset. For a user to update the ZIP, go to replace pg just like any other file, same upload method widgets available on upload pg will be available on replace pg.
For consideration: could the upload widget on the replace pg retain the GitHub repo URL?
Replace: See Edit. Allow users to replace the ZIP just like any other file deposited into a dataset.
For a published 2.0 version, the new zip to be a replaced version of the zip in the 1.0 version. Users can see that files were replaced vs deleted and added on the versions tab.
Mock up (digital) the UI and relevant messages (on-page help, tool tips, success/error message text) for release 1:
Create dataset page
File replace page
Review and refine
Create test plan, recruit participants, conduct testing
Revise if/as needed
Finalize mockups and UI behavior for development
The text was updated successfully, but these errors were encountered: