You spent two years making a method work. The paper is out, and now the real test begins: will anyone outside your lab actually use it?
A methods paper is promoted differently from a findings paper. Nobody shares a method because it is surprising. They use it because it solves a problem they have this week, and because they can get it running without emailing you three times. Most of the promotion is making that easy, then telling the right people.
Why Methods Papers Need a Different Plan
A findings paper asks readers to believe something. A methods paper asks them to do something, which is a much bigger request. They have to trust it, find every step, get the code or reagents working and know how to cite it.
The paper itself rarely carries all of that. Bio-protocol puts it plainly: the traditional methods section of a research article is often brief and incomplete, making it difficult to replicate experiments without extensive troubleshooting. If a reader hits that wall, your promotion has done its job and the method still goes unused.
So the plan has two halves. First, remove the friction between "this looks useful" and "it works in my lab". Then point the people who have the problem at the method.
Make the Method Easy to Find, Try and Cite
Each thing a would-be user needs has a natural home. You probably do not need all of them, but every gap is a place where a curious reader gives up.
| What a would-be user needs | Where it can live | What the source says |
|---|---|---|
| Every step, at bench detail | A citable protocol on protocols.io or in the Bio-protocol journal | protocols.io says a citable protocol published with your paper gets you credit for the method development and increases reproducibility |
| A stable version of the code | A Zenodo archive of your public GitHub repository | GitHub's documentation says Zenodo can only access public repositories, and issues a new DOI each time you create a release |
| The right way to cite it | A CITATION.cff file in the repository | GitHub adds a "Cite this repository" link with APA and BibTeX |
| Permission to reuse | A license in the repository | GitHub's Zenodo guidance recommends a license so readers know how they can reuse your work |
| A reason to try it | One plain sentence on the problem it solves | Your post, your lab page and the first line of the README |
Getting the DOI is quick. GitHub's steps are to log in to Zenodo with GitHub, authorize it and switch the repository on; Zenodo then archives it and issues a new DOI each time you create a GitHub release.
Two details in that table matter more than they look.
Point the citation at your paper
A CITATION.cff file is, in the words of the Citation File Format site, a plain text file with human and machine readable citation information for software and datasets. Once it is on the default branch, GitHub adds a "Cite this repository" link to the repository landing page.
The file describes your software, but GitHub's documentation shows how a preferred-citation entry can point people to a journal article instead. If you want reuse to count toward the methods paper, say so in the file.
Name the version people should use
The Citation File Format site lists the questions a would-be citer probably cannot answer accurately on their own: what the software is called (it is probably not analysis.py), which version they used and who the authors are. A CITATION.cff plus a release with a DOI and a version number answers all three. The same site notes that Zenodo can reuse the metadata in your CITATION.cff when you publish a release through its GitHub integration.
A Worked Example
Say, as a hypothetical, that you published a methods paper on a faster way to segment cells in fluorescence microscopy images, with an open-source Python tool.
- Weak post: "Our new paper introduces SegFast, a novel deep learning pipeline for cell segmentation. Link below." It names the method, not the problem, and gives the reader nothing to try.
- Better post: "If you spend hours hand-correcting cell outlines in crowded fluorescence images, we built a tool for that. The paper shows where it works and where it does not; the code, a sample dataset and a step-by-step protocol are all linked, with a DOI for the version we tested." It leads with the pain, admits the limits and puts the next step one click away.
Behind the better post, the repository has a release archived on Zenodo, a CITATION.cff with the paper as the preferred citation, a license and a README whose first line repeats the problem in plain words. The protocol lives somewhere a bench scientist can follow it without the paper open.
If your method comes with data, the guide to promoting a research dataset covers that side. If it is a machine learning method, see promoting a machine learning paper beyond arXiv.
A Checklist Before You Share
- Write one sentence on the problem the method solves and who has it.
- Publish the full protocol somewhere citable, and link it from the paper's page.
- Archive the code with a DOI and name the version the paper used.
- Add a
CITATION.cffthat points to the paper, and a license. - Say plainly where the method does not work yet.
- Lead every post with the problem, not the method's name.
- Share it where people with that problem already gather: the relevant lab groups, mailing lists and conference sessions.
Where Amplify Fits
The hardest part of promoting a method is explaining, in a minute, what it does and who should care. Amplify turns the PDF you upload into a video abstract (16:9, about 3 minutes), a vertical short (9:16, 45 to 60 seconds), an audio brief and a one-page infographic, generated from your paper and nothing else, with no open-web filler. Every artifact carries the title, the authors and a link back to the paper of record.
Each format arrives as three variants you can edit line by line or regenerate, so the opening can lead with the problem the way your best post does. A subject-matter reviewer reads every draft before it can leave your workspace, every claim is traced to a page in the PDF, and nothing publishes until you approve it.
The embeddable widget puts every format beside the paper on your lab site or project page, where readers can read, listen and chat with the paper without leaving the page. Analytics show reads, listens, questions asked, languages and which format moved people, which is useful for grant reports and broader-impact sections. You keep ownership of your work, ResearchBunny does not train on it, and you can delete a paper and its artifacts at any time.
A method only matters once someone else runs it. Make the first try easy, tell the people who need it, and let the citations follow the reuse.
