).
diff --git a/_guidance/preparing-replication-package-submit.md b/_guidance/preparing-replication-package-submit.md
new file mode 100644
index 00000000..054053fc
--- /dev/null
+++ b/_guidance/preparing-replication-package-submit.md
@@ -0,0 +1,36 @@
+---
+title: "Submitting"
+toc: true
+date: 2026-08-10
+---
+
+[◀ Back to Checklist](preparing-replication-package) | [Back to Details](preparing-replication-package-details) | [◀ Previous: Finalize README](preparing-replication-package-finalize)
+
+You can now submit your replication package to the Data Editor.
+
+In all cases, the [**completed checklist**](preparing-replication-package#checklist) should be sent directly to the Data Editor, using `reply-all` to the email that you received from the Data Editor.
+
+## If you ran using SIVACOR {#sivacor}
+
+From the [output from SIVACOR](https://docs.sivacor.org/docs/step4-download/), you should
+
+- use the `Replicated Package` ZIP file, and **replace the entire content** of your draft openICPSR deposit.
+- not remove any files from the ZIP file.
+- upload the ZIP file using the ["Import"](data-deposit-aea#importing-zip-files) function in your draft openICPSR deposit.
+
+
+The ZIP file contains your entire upload (minus any explicitly deleted files!), plus any generated output and log files, as well as the **certificate** which documents that you ran this replication package through SIVACOR.
+
+You do not need to email any of the log files or output to the Data Editor separately.
+
+## Submitting other checked code
+
+In addition to the checklist, update the journal deposit with any updated code, data, and README. Ideally, you should also include and document the outputs and log files generated by your reproducible run. In the interest of transparency, these will be published as part of the replication package, without further edits.
+
+However, if you prefer, you can submit the generated logfiles as evidence by email.
+
+## Mark the deposit as complete
+
+In all cases, you should mark the openICPSR deposit as **complete** by [re-submitting it](faq#i-was-asked-to-modify-files-in-my-repository-not-yet-published-but-i-cannot-upload-or-edit-anything).
+
+## You are done.
diff --git a/_guidance/preparing-replication-package.md b/_guidance/preparing-replication-package.md
index c162e0fd..c2b30187 100644
--- a/_guidance/preparing-replication-package.md
+++ b/_guidance/preparing-replication-package.md
@@ -9,9 +9,9 @@ date: 2025-12-04
This document describes how to prepare your code for verification, taking into account some of the most frequent issues that the Data Editor and his team have encountered in submitted replication packages.
-> ⚠️❗ **IMPORTANT:** At this point, you should only be seeing this page if you were asked by the Data Editor team to do so. If using multiple software in the replication package, you must be able to split the processing into a reasonably small set of single-software master scripts (see [SIVACOR documentation](https://docs.sivacor.org/docs/step0-prepare/#your-replication-package-only-uses-a-single-software-application-per-step)). Only a limited set of software are feasible at this time (see [Step 5 section: authorized containers](#authorized-containers)).
+> ⚠️❗ **IMPORTANT:** At this point, you should only be seeing this page if you were asked by the Data Editor team to do so. If using multiple software in the replication package, you must be able to split the processing into a reasonably small set of single-software master scripts (see [SIVACOR documentation](https://docs.sivacor.org/docs/step0-prepare/#your-replication-package-only-uses-a-single-software-application-per-step)). Only a limited set of software are feasible at this time (see [Step 5 section: authorized containers](preparing-replication-package-step5#authorized-containers)).
>
-> You do NOT need to know how Docker or similar software works, nor do you need to be able to run containers on your own computer (though it helps). See [Step 5 section: Using the SIVACOR website](#using-the-sivacor-website).
+> You do NOT need to know how Docker or similar software works, nor do you need to be able to run containers on your own computer (though it helps). See [Step 5 section: Using the SIVACOR website](preparing-replication-package-step5#using-the-sivacor-website).
## Overview
@@ -43,22 +43,22 @@ The AI will work through each step with you, identify issues, and suggest specif
Print off (as PDF or on paper) the following checklist, and tick off each item as you complete it. Provide the completed checklist as part of the replication package.
-- [ ] [**Step 1: Main file**](preparing-replication-package-step1): A single main file is provided that runs all code. [Details](preparing-replication-package-step1)
-- [ ] [**Step 2: Path names**](preparing-replication-package-step2): All paths in code use `/` (forward slashes) relative to a single top-level project directory (`$rootdir`, `$basedir`, etc.). The top-level project directory is set dynamically, not hard-coded (explanations below). [Details](preparing-replication-package-step2)
-- [ ] [**Step 3: Dependencies**](preparing-replication-package-step3): All packages/libraries/dependencies are installed via code once. [Details](preparing-replication-package-step3)
+- [ ] [**Step 1: Main file**](preparing-replication-package-step1): A single main file (or a very small number of single-software main files) is provided that runs all code. [▶](preparing-replication-package-step1)
+- [ ] [**Step 2: Path names**](preparing-replication-package-step2): All paths in code use `/` (forward slashes) relative to a single top-level project directory (`$rootdir`, `$basedir`, etc.). The top-level project directory is set dynamically, not hard-coded (explanations below). [▶](preparing-replication-package-step2)
+- [ ] [**Step 3: Dependencies**](preparing-replication-package-step3): All packages/libraries/dependencies are installed via code once. [▶](preparing-replication-package-step3)
- [ ] For Stata, these packages are installed into a subdirectory in the project (`$rootdir/ado`, `$basedir/adofiles`, etc.), and used by the code.
- [ ] For R, `renv` is used (exceptions made for other package management systems if such a system is explained).
- [ ] For Python, environments are used (native `venv` or `conda`), and the necessary top-level requirements specified (no OS-specific dependencies are included).
-- [ ] [**Step 4: Displays**](preparing-replication-package-step4): All figures and tables are written out to clearly identified external files, and the authors' versions, as used in the manuscript, are provided. [Details](preparing-replication-package-step4)
-- [ ] [**Step 5: Testing on AEA-maintained website**](preparing-replication-package-step5): After all changes were made, the code was run using the referenced website, a certified ZIP file was created, and is provided instead of the original replication package (alternatives exist for certain situations). [Details](preparing-replication-package-step5)
-- [ ] (usually not necessary) [**Finalize**](preparing-replication-package-finalize): Update the README with the necessary information about computer specifications, Docker image used, memory and disk space requirements, and expected runtime.
+- [ ] [**Step 4: Displays**](preparing-replication-package-step4): All figures and tables are written out to clearly identified external files, and the authors' versions, as used in the manuscript, are provided. [▶](preparing-replication-package-step4)
+- [ ] [**Step 5: Testing on AEA-maintained website**](preparing-replication-package-step5): After all changes were made, the code was run using the referenced website, a certified ZIP file was created, and is provided instead of the original replication package (alternatives exist for certain situations). [▶](preparing-replication-package-step5)
+- [ ] (usually not necessary) [**Finalize**](preparing-replication-package-finalize): Update the README with the necessary information about computer specifications, Docker image used, memory and disk space requirements, and expected runtime. [▶](preparing-replication-package-finalize)
## Submitting
-You can now submit your replication package to the Data Editor, along with the completed checklist from above, and the generated `main.log`/`main.Rout` as evidence.
+You can now submit your replication package to the Data Editor, along with the completed checklist from above, and the generated `main.log`/`main.Rout` as evidence. See the [Submitting](preparing-replication-package-submit) page for details.
## Problems?
diff --git a/_posts/2026-08-12-PSM-Github.md b/_posts/2026-08-12-PSM-Github.md
new file mode 100644
index 00000000..500dd974
--- /dev/null
+++ b/_posts/2026-08-12-PSM-Github.md
@@ -0,0 +1,85 @@
+---
+title: "PSA: Please be precise when using Github as input to scientific articles."
+categories: dataeditor
+date: 2026-08-12
+mastodon:
+bluesky:
+tags:
+ - data editor tips
+ - reproducibility
+ - data citation
+ - Github
+ - licenses
+---
+
+If you use Github as an deposit for your scientific output, or you are re-using somebody else's Github deposit, please be precise. I have some thoughts...
+
+
+
+
+From a recent (draft) replication package:
+
+> Data on Kelly et al. (2021)'s patent indicator are downloaded from the authors’ GitHub repository. A copy of the data is provided as part of this archive. The data are in the public domain. To download, visit at https://github.com/KPSS2017, click the pinned repository named "Measuring-Technological-Innovation-Over-the-Long-Run-Extended-Data," and download "PatentSimilarityImportanceBreakthrough_forPost2022.csv.zip".
+
+A few things, first for those re-using the data, and then for those providing the data.
+
+## For re-users
+
+### Citing
+
+If using the Github data, and not the replication package to the original article, the Github data must be cited. Here, that would be
+
+> Kelly, B., Papanikolaou, D., Seru, A. and Taddy, M. 2023. *Updates and Extension of Measuring Technological Innovation Over the Long Run*. https://github.com/KPSS2017/Measuring-Technological-Innovation-Over-the-Long-Run-Extended-Data, version from November 2023.
+
+On the [Github README](https://github.com/KPSS2017/Measuring-Technological-Innovation-Over-the-Long-Run-Extended-Data/blob/main/README.md), the authors actually say
+
+> The version released on Sept 29, 2023 is the latest.
+
+but the [commits](https://github.com/KPSS2017/Measuring-Technological-Innovation-Over-the-Long-Run-Extended-Data/commits/main/) on the Github actually tell a different story: there are September and November updates to the deposit. Whether those are materially different is not clear (these are ZIP files), but as a re-user, you should identify the version you ACTUALLY used.
+
+Note that the authors ask that their published article be cited as a source. That is fine, as long as the re-user ALSO cites the actual source of the data, which is Github.
+
+### Downloading
+
+The very verbose description is actually not the best way. First, the actual Github repository has a direct link. The *pinned* repositories can change over time, without any reason. Re-users should not rely on that. In fact, as I mentioned above, there are multiple commits. Unless the Github owners manipulate those commits (possible), the specific commit is what should be identified, possibly in the citation, but definitely in the download instructions. Here is the same verbose instructions expressed as a single URL:
+
+> Download
+>
+
+which preserves the metadata (it doesn't directly download the data, but rather, allows you to see the context in which you are downloading the data). Much simpler.
+
+### Distributing
+
+The quote I provided mentions "data are in the public domain." That is incorrect. The data are downloadable by anybody without registration. However, "public domain" is a legal term that means that nobody has the copyright on the data. Possibly because the entity producing the data is legally excluded from claiming copyright (oversimplifying somewhat, in the US, the federal government), or because the person producing the data has explicitly relinquished this (often under a "CC0" license).
+
+But in the absence of true "public domain", the data are copyrighted by the original authors. Fair-use is fine (so using the data is likely the intent of posting it on the internet here), but re-purposing the data may not be. Copyright = all rights reserved does not need an explicit mention! So strictly speaking, you need the authors' permission to redistribute the data, or you might have to claim "fair use" explicitly. We usually send the re-users to ask permission, which is cleaner.
+
+## For authors
+
+All of the above can be greatly simplified if authors (those posting on Github) followed some simple best practices:
+
+### Define a license
+
+Authors should clearly specify the license under which the data are released. Common licenses include Creative Commons (CC) licenses, which allow for various levels of reuse of data, or open-source software licenses like MIT or GPL, which might be more relevant for code. A dual-license setup can work. See [guidance](https://aeadataeditor.github.io/aea-de-guidance/Licensing_guidance) on my website. The license should be expressed as a `LICENSE.txt` or `LICENSE.md` file in the root of the repository, it will be picked up and displayed in the sidebar by Github.
+
+If authors do NOT want to provide a general license, that is also fine, but they should likely explicitly say it, to be clear, although that may not be legally required: "Copyright John Doe and Alice Smith, all rights reserved. Permission to redistribute or reuse this data must be obtained from the authors."
+
+### Versioning
+
+Rather than having re-users guess at versions, and have long commit-based URLs, create tags or releases. Very easy to do in both `git` and on Github. That would allow for much simpler URLs:
+
+> Download [https://github.com/KPSS2017/Measuring-Technological-Innovation-Over-the-Long-Run-Extended-Data/blob/ **v1.1** /PatentSimilarityImportanceBreakthrough_forPost2022.csv.zip](https://github.com/KPSS2017/Measuring-Technological-Innovation-Over-the-Long-Run-Extended-Data/blob/v1.1/PatentSimilarityImportanceBreakthrough_forPost2022.csv.zip)
+
+(OK, that's not much shorter in this case, because of the long repository and file names, but it is easier to read).
+
+### Citation
+
+Authors in general prefer that you cite the article, because under current academic norms (at least in economics), is the only thing that counts. Nevertheless, if the article is published in 2021, and the data in 2023, re-users are misleading their readers because they materially reference data that does not exist at the cited location (the article, or its replication package), and cannot be easily linked. The solution is to cite both.
+
+And to make that easy, use the [CITATION.cff](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-citation-files) file. It, too, is highlighted by Github in the right panel.
+
+### Preserving
+
+And finally, if you have license and citation all tidied up, why not preserve it, and get a DOI to boot? This does away with the fragility of deposits and commits (anybody can delete their Github repo forever, in 30 seconds flat), and simplifies citation as well. You can do so nearly automatically (if creating releases) [via Zenodo](https://docs.github.com/en/repositories/archiving-a-github-repository/referencing-and-citing-content), or to [Dataverse](https://github.com/marketplace/actions/dataverse-uploader-action).
+
+Re-users can then simply use the Zenodo version, which has a DOI, and is guaranteed to be preserved.
\ No newline at end of file