See the wiki for a description of the accompanying research infrastructure and instructions on how to best use various tools.
Your idea is solid enough that you chose to initialize this repo. Congrats! But before you proceed, you need to demonstrate that there’s a market for your work. It’s time to write your project’s prospectus.
The first step is to clarify what your work is. You’ll do that by writing down the RAP+M for the project:
- R
- research question
- A
- (type of expected) answer
- P
- position
- M
- method (data + model + estimation)
You’ll revise your RAP+M countless times as you develop this project. That’s expected! Even so, do your best now to write down a RAP+M that is specific and attainable. Avoid sinking time into a project that simply can’t be done.
With your RAP+M in hand, move through the subsequent checklist to evaluate the demand for this project. Economists demand work that moves their priors on questions of large practical or theoretical consequence (or establishes their priors where they did not heretofore exist). By the end of the checklist, you should be able to judge what sort of economists would read your paper and with how keen of interest they would do so.
The checklist is broken into two sections. The first gauges how likely it is for your paper to be widely read. The second gauges how likely it is that others will build on your work. To see the distinction, think about a paper like Arkolakis, Costinot, & Rodriguez-Clare (2012) vs. papers like Dixit & Stiglitz (1977) or Eaton & Kortum (2002) (apologies to non-trade economists who read this!). All trade economists know the main result of the former—that all gravity models deliver the same simple formula for the gains from trade—while few remember the main results of the latter two. And yet, those two have been cited >18k times combined because they provide theoretical frameworks that are applicable to a wide set of problems. Accordingly, a large number of checkmarks in either section is sufficient to justify continued work.
(Note: This checklist is adapted from J. Horton (2015)).
- [ ] the theory being tested is new
- [ ] the data needed to do the analysis didn’t exist
- [ ] the reduced-form results needed to motivate the model didn’t exist
- [ ] there’s been technological change of some kind that makes this question more important
- [ ] no one has thought of it before, even though paper has long been possible (unlikely!)
Where, precisely, would the paper be cited in a standard graduate text or handbook for its relevant fields?
List five follow-up projects that one could feasibly do once the questions from this project are answered
A place to track correspondence between coauthors, RAs, and advisors. Any medium fits: email, Slack, Zoom/Skype, in-person meetings, and so on. Notes for regularly-scheduled meetings are stored in Asana inside the relevant meeting agenda, but loose notes from side conversations can be dumped here.
A place to list relevant papers. Papers are identified and linked by
their orb citation keys. All notes on those papers ought to be kept
separately in your orb database to facilitate reuse across projects,
with the exception of a brief blurb about the paper’s relevance to
this particular project.
A place to list relevant datasets. Datasets are identified and linked
by their orb citation keys. All notes on those datasets ought to be
kept separately in your orb database to facilitate reuse across
projects, with the exception of a brief blurb about the dataset’s
relevance to this particular project.
A place to record and answer questions that you have been (or expect
to be) asked about some component of your project. Some questions can
be answered outright; others will generate tasks (into Backlog or
directly into a sprint) that must be completed in order to arrive at
an answer. Well-posed questions from Feedback should be refiled
here. The final exposition of your paper should address each of the
questions listed here.
A place to store deep work tasks that have not yet been incorporated into a sprint.
A place to track the execution of the project. Most tasks included in a numbered sprint will be instances of deep work. Shallow work, by contrast, will be stored under its own heading. Shallow tasks, like reformating text and refactoring cruft, are best done in batches when you’re feeling relatively unproductive.
A place to track correspondence with folks outside the research team, including referees, editors, and discussants. Any medium fits: email, Zoom/Skype, in-person meetings, and so on.
A place to store any notes that have not been converted into tasks nor incorporated into the paper’s exposition. Or, if you’re not sure where something belongs, just toss it here.