|
1 |
| -<!--your zenodo badge here--> |
2 | 1 |
|
3 |
| -># meta-repository |
4 |
| ->Template repository for a single point of access meta-repository to reproduce an experiment |
5 |
| -> |
6 |
| ->## Instructions for use |
7 |
| ->NOTE: Delete this instructional section after creating your template! |
8 |
| -> |
9 |
| ->### Purpose |
10 |
| ->A meta-repository allows us to create a single point of access for someone to find all of the components that were used to create a published work for the purpose of reproducibility. This repository should contain references to all minted data and software as well as house any ancillary code used to transform the source data, create figures for your publication, conduct the experiment, and / or execute the contributing software. |
11 |
| -> |
12 |
| ->### Using the Template |
13 |
| ->Simply click `Use this template` on the main repository page (shows up to the left of `Clone or download`) and fill in your `Repository name`, the `Description`, select whether you want the repository to be `Public` or `Private`, and leave `Include all branches` unchecked. |
14 |
| -> |
15 |
| ->### Naming your meta-repository |
16 |
| ->The following naming conventions should be used when naming your repository: |
17 |
| ->- Single author: `lastname_year_journal` |
18 |
| ->- Multi author: `lastname-etal_year_journal` |
19 |
| ->- Multiple publications in the same journal: `lastname-etal_year-letter_journal` (e.g., `human-etal_2020-b_nature`) |
20 |
| -> |
21 |
| ->### Cutomize your `.gitignore` file |
22 |
| ->A general `.gitignore` for use with Python development is included. However, you may wish to customize this to the needs of your project. |
23 |
| -> |
24 |
| ->### Suggestions |
25 |
| ->- Don't bog down your repository with a bunch of raw data. Instead archive and mint a DOI for your data and provide the reference in this repository with instructions for use. |
26 |
| ->- Create complete and tested documentation for how to use what is in this repository to reproduce your experiment. |
27 |
| -> |
28 |
| ->### Creating a minted release for your meta-repository |
29 |
| ->It is important to version and release your meta-repository as well due to changes that may occur during the publication review process. If you do not know how to conduct a release on GitHub when linked with Zenodo, please contact [email protected] to get set up. The first line of this file is a space holder for your Zenodo DOI badge. |
30 |
| -> |
31 |
| -> |
32 |
| ->### The following is the template for you to fill in with your own information |
33 | 2 |
|
| 3 | +# metarepo |
| 4 | +Template repository for a single point of access meta-repository to reproduce an experiment |
34 | 5 |
|
35 |
| -# lastname-etal_year_journal |
36 |
| -One sentence describing your research |
| 6 | +## Purpose |
| 7 | +A meta-repository creates a single point of access for someone to find all of the components that were used to create a published work for the purpose of reproducibility. This repository should contain references to all minted data and software as well as house any ancillary code used to transform the source data, create figures for your publication, conduct the experiment, and / or execute the contributing software. |
37 | 8 |
|
38 |
| -## Abstract |
39 |
| -Your abstract here. |
| 9 | +## Using the template |
| 10 | +Simply click `Use this template` on the main repository page (shows up to the left of `Clone or download`) and fill in your `Repository name`, the `Description`, select whether you want the repository to be `Public` or `Private`, and leave `Include all branches` unchecked. |
40 | 11 |
|
41 |
| -## Code reference |
42 |
| -References for each minted software release for all code involved. If you have modified a codebase that is outside of a formal release, and the modifications are not planned on being merged back into a version, fork the parent repository and add a `.<shortname>` to the version number of the parent and conduct your own name. For example, `v1.2.5.hydro`. |
| 12 | +## Naming your meta-repository |
| 13 | +The following naming conventions should be used when naming your repository: |
| 14 | +- Single author: `lastname_year_journal` |
| 15 | +- Multi author: `lastname-etal_year_journal` |
| 16 | +- Multiple publications in the same journal: `lastname-etal_year-letter_journal` (e.g., `human-etal_2020-b_nature`) |
43 | 17 |
|
44 |
| -#### Example: |
| 18 | +## Customize your `.gitignore` file |
| 19 | +A general `.gitignore` for use with Python or R development is included. However, you may wish to customize this to the needs of your project. The `.gitignore` file lets Git know what to push to the remote repository and what needs to be ignored and stay local. |
45 | 20 |
|
46 |
| -Human, I.M. (2020, January 1). human/myrepo: v1.2.5.hydro (Version v1.2.5.hydro). Zenodo. https://doi.org/some-doi-number |
| 21 | +## Suggestions |
| 22 | +- Don't bog down your repository with a bunch of raw data. Instead archive and mint a DOI for your data and provide the reference in this repository with instructions for use. |
| 23 | +- Create complete and tested documentation for how to use what is in this repository to reproduce your experiment. |
47 | 24 |
|
48 |
| -## Journal reference |
49 |
| -Update your journal reference here after acceptance. |
| 25 | +## Creating a minted release for your meta-repository |
| 26 | +It is important to version and release your meta-repository as well due to changes that may occur during the publication review process. If you do not know how to conduct a release on GitHub when linked with Zenodo, please contact [email protected] to get set up. |
50 | 27 |
|
51 |
| -## Data reference |
52 |
| - |
53 |
| -### Input data |
54 |
| -Reference for each minted data source for your input data. |
55 |
| - |
56 |
| -#### Example: |
57 |
| - |
58 |
| -Human, I.M. (2020). My dataset name [Data set]. DataHub. https://doi.org/some-doi-number |
59 |
| - |
60 |
| -### Output data |
61 |
| -Reference for each minted data source for your output data. |
62 |
| - |
63 |
| -## Contributing models |
64 |
| -| Model | Version | Repository Link | DOI | |
65 |
| -|-------|---------|-----------------|-----| |
66 |
| -| <model 1> | <version> | <link to code repository> | <link to DOI dataset> | |
67 |
| -| <model 2> | <version> | <link to code repository> | <link to DOI dataset> | |
68 |
| - |
69 |
| -## Reproduce my experiement |
70 |
| -Fill in detailed info here or link to other documentation that is a thorough walkthrough of how to use what is in this repository to reproduce your experiment. |
| 28 | +## The meta-repository markdown template |
| 29 | +A sample meta-repository template is provided in this repository in the file `metarepo_template.md`. |
71 | 30 |
|
| 31 | +To use it, do the following: |
| 32 | +1. Create the template repository as mentioned above in [Using the template](#using-the-template) |
| 33 | +2. Clone your new repository to you local machine |
| 34 | +3. Change directories into your new meta-repository directory you just cloned |
| 35 | +4. Run `git rm README.md` to delete this file (`README.md`) and commit it using `git commit -m 'remove instructions'` |
| 36 | +5. Rename `metarepo_template.md` as `README.md` |
| 37 | +6. Run `git add README.md` to stage the new file that will show up on load in your remote GitHub repository |
| 38 | +7. Run `git rm metarepo_template.md` to remove the original template |
| 39 | +8. Run `git commit -m 'set up new template as readme'` to set the changes |
| 40 | +9. Run `git push` to send the changes to your remote GitHub repository |
| 41 | +10. Modify the `README.md` file to represent your experiement and use the `add`, `commit`, `push` workflow to update your remote repository |
0 commit comments