Publication & Archiving
Figure standards, code release, data deposition, the manuscript process, and what it means to close a project properly.
§1 Figure standards
Figures are the primary medium through which scientific findings are communicated to readers. The standards below apply to all figures in manuscripts, preprints, posters, and presentations produced by the lab.
Technical specifications
| Parameter | Standard |
|---|---|
| File format | 300 dpi PNG for export. Illustrator source files (.ai) preserved alongside all exports. |
| Assembly software | Adobe Illustrator is the lab standard. Open-source vector-based alternatives (e.g., Inkscape) are acceptable provided they support file linking rather than embedding. File linking is the critical feature: it allows source panels to be updated without rebuilding the entire figure. |
| File linking | All panels placed into an Illustrator file must be linked, not embedded. |
| Fonts | Sans-serif only: Arial or Helvetica. No readable text should be smaller than 6 pt in the final exported figure. |
| Color | Colors must be distinguishable from one another. Any color encoding that requires interpretation must include a legend. |
| Axes | All axes must be labeled. Units must be included wherever applicable. |
| Quality check | Every exported PNG must be inspected at high zoom for pixelation or rendering artifacts before use. Correct and re-export if any are found. |
Building a publication-quality figure set is a multi-month process. Start early, get feedback from colleagues and from the PI throughout, and expect to revise significantly. Most things that seem clear to the person who ran the analysis are not clear to a reader seeing the figure for the first time.
§2 Image integrity
How data moves from its source to a figure panel is a scientific and ethical question. The following pipelines define what is acceptable.
Computational outputs
Computational outputs should flow directly from R to disk to Illustrator. The figure should represent exactly what the analysis produced.
Microscopy and imaging outputs
Microscopy and Xenium images may be cropped or minimally adjusted (brightness, contrast) between raw capture and Illustrator, provided those adjustments are applied uniformly and are disclosed in the methods. The raw capture must be preserved on the lab server.
No modification may be made to any figure panel that misrepresents what was measured or observed. This includes selectively cropping to hide unfavorable data, adjusting contrast to obscure or emphasize features differentially, or any other alteration that would cause a reader to draw a different conclusion than the underlying data supports. This constitutes research misconduct. When in doubt about whether an adjustment is appropriate, ask before making it.
§3 Code release
Every publication from this lab should have an associated GitHub repository containing the code used to produce it. In most cases this will be an existing RaredonLab repository made public at the time of submission or publication. When a paper draws from multiple repositories, the README should clearly identify all of them.
What should be in the released repository
The minimum is an organized code deposit: scripts that run in a clear sequence, a README explaining what they do and in what order. Strive for better than the minimum. The ideal release includes:
- A clear README with a project overview, data access instructions, and a walkthrough of the analysis sequence
- Well-annotated scripts following the naming conventions in Document 04
- Knit HTML vignettes in
docs/that demonstrate key analytical steps - A formal R package, if the work produced generalizable tools
The purpose of releasing code is to help others learn from and build on the lab's work. A repository that achieves this is a contribution to the field beyond the paper itself.
Before making a repository public
Review the repository for any proprietary material before changing its visibility to public. This is rare, but it must be checked. Confirm with the PI that the repository is ready for release before making it public.
§4 Data deposition
Both raw and processed data should be deposited at the time of publication. The lab uses two repositories:
| Repository | What goes there | Link |
|---|---|---|
| GEO (NCBI Gene Expression Omnibus) | Raw and processed sequencing data: scRNAseq, spatial transcriptomics, bulk RNA-seq | ncbi.nlm.nih.gov/geo |
| Figshare | Processed data objects, supplementary files, and any data that does not fit GEO requirements | figshare.com |
Metadata and documentation
Deposited data should be clean, clearly labeled, and comprehensive. The goal is to make it easy for other labs to find, understand, and use what you have generated. Include metadata that fully describes the samples, conditions, processing steps, and any relevant experimental parameters. Vague or incomplete metadata devalues a dataset significantly.
Confirm with the PI before releasing any data or metadata publicly. Timing, embargo periods, and scope of release all require PI involvement.
§5 The manuscript process
The following sequence applies to every manuscript submitted from this lab. First authors are responsible for managing this process and keeping it moving. Additional detail on first author responsibilities is in the General Lab Manual (in development).
-
1
First author writes and assembles. The first author writes the manuscript, assembles all figures, and prepares all supplementary materials to a complete, submission-ready state.
-
2
First author sends complete draft to PI. The PI reviews and returns written edits. Partial drafts may also be sent, as the first author deems appropriate, if interim feedback would be useful.
-
3
First author addresses PI edits, then sends to the full authorship team. Co-authors may return comments. The first author addresses all of them.
-
4
First author sends the revised draft to the PI for final approval. Once approval is given, the first author organizes and proofreads all submission materials.
-
5
First author schedules a submission meeting with the PI. The manuscript is submitted together, in person, in a one-hour meeting. This is standard practice for every submission from this lab.
-
6
For each round of peer review: the first author addresses all reviewer comments and requested revisions, returns the finished revised manuscript to the PI, and schedules a re-submission meeting as before. Every revision follows the same process as the original submission.
The PI is the corresponding author on all papers by default. In exceptional cases, the first author may be elevated to co-corresponding author by the PI's decision. All communication with journal editors, at every stage, must involve the PI.
Preprints
Whether and when to post a preprint is decided on a case-by-case basis. Both the benefits (rapid dissemination, establishing priority) and the costs (reduced novelty for high-impact journals, public exposure before peer review) vary by project and target journal. Discuss the preprint strategy with the PI early in the manuscript process.
§6 Archiving at publication
A project is considered complete when the paper has been peer-reviewed and published. At that point, a final round of organization should confirm that the following are in place.
On the Raredon Lab server
- All data, processed objects, figures, and submission materials are present and organized
- A README file in the project directory identifies all materials by name, describes the directory structure, and points to the corresponding GitHub repository and public data deposits
- Intermediate files that are no longer needed have been cleaned up (see Document 05 §4 on post-publication housekeeping)
On GitHub
- The associated repository is public (or has been confirmed with the PI to remain private)
- The README links to the published paper, the GEO accession, and the Figshare deposit
- All code runs cleanly from a fresh environment
Public data deposits
- GEO and Figshare accession numbers are recorded in the paper and in the server README
- Any embargo periods have expired or are tracked for future release
A well-archived project allows other scientists to reproduce your findings, build on your methods, and trust your results. It is also the record that future lab members will rely on to understand the lab's prior work. The effort put into archiving a project is a contribution that outlasts the paper itself.