A New Project Starts Monday and Nobody Has Built the Reading List

A new project starts Monday, and the reading list does not exist yet. Maybe you have a folder of PDFs from a winter-break cleanup, a supervisor's margin comments on a draft chapter, and a vague sense that the literature is out there but not yet assembled. The task is not to read everything. It is to build a defensible, documented reading list that you can defend to a supervisor, reuse in your next manuscript, and extend without starting over.

This article walks through that repair as a concrete case: a January project start for a thesis chapter, where the student has scattered notes but no organized literature base. It shows the starting state, the decisions that turn a pile of papers into a reading list, the artifacts you need, and how to know the list is ready. Along the way, it connects specific WisPaper tools only at the steps where they genuinely help.

Most stalled reading lists fail for a boring reason: nobody defined what the list is for. Before opening a search box, write down three things.

First, the scope question. What is this project actually asking? A thesis chapter on a specific mechanism, a coursework paper on a defined topic, or a first manuscript extending prior work each need a different boundary. Write the question in one sentence and keep it visible.

Second, the eligibility criteria. Cochrane guidance on searching recommends planning searches from eligibility criteria rather than from whatever terms come to mind. That means deciding in advance what kinds of studies, methods, populations, or time periods count, and what falls outside. This is the single decision that most changes the shape of the list.

Third, the existing material. Inventory what you already have: PDFs, notes, supervisor comments, references cited in your last draft. A winter-break cleanup often produces a folder of papers with no labels. That folder is raw material, not a reading list.

A quick diagnostic: if you cannot state your scope question and eligibility criteria in two or three sentences, you are not ready to search. If you can, you are ready to build.

A reading list serves at least three different jobs, and they pull in different directions:

• Coverage: making sure the key work in a field is represented.
• Argument: assembling the specific sources your chapter or paper will cite.
• Method: documenting how you searched, so the process is transparent and repeatable.

For a first manuscript or thesis chapter, you usually need all three, but in a specific order. Coverage comes first, because you cannot argue from sources you have not found. Method runs alongside, because documenting as you go is far cheaper than reconstructing your search later. Argument comes last, when you select the subset you will actually cite.

Write this down as a short project note: scope question, eligibility criteria, and the three jobs. That note becomes the front matter of your reading list and the first artifact of the project.

Cochrane's guidance is direct: plan searches from eligibility criteria, use multiple sources, and combine free-text terms with subject headings. For a student project, that translates into a practical search plan.

1. Derive terms from your criteria. Turn each eligibility criterion into search terms. If your scope includes a method, a population, and a time window, each becomes a term or a filter.
2. Use more than one source. A single database or search interface will miss relevant work. Plan at least two entry points.
3. Combine free-text and controlled vocabulary. Free-text terms catch new phrasing; subject headings catch indexed work under standard labels.
4. Record the plan before you run it. Note the terms, sources, and any filters. This is the seed of your methods documentation.

This is where a scholarly search interface earns its place. If you want a single place to run academic paper searches, WisPaper search provides a scholarly search interface for finding academic papers. For readers who want a public entry point to finding academic papers, WisPaper Scholar Search explains and opens that search. Neither replaces your plan; they execute it.

As you search, capture every candidate record in one place. The temptation is to download PDFs into a folder and move on. Resist it. Capture the record, the source, and the date.

Cochrane guidance also covers the downstream steps: document the process, deduplicate records, and screen in stages. Those steps are easier if your capture is consistent from the first search. A simple record table with columns for title, authors, year, source, and a screening status will carry you through the whole project.

If your search produces a long candidate list, you can hand the heavier literature-review work to an agent built for longer research tasks. Scholar Agent supports literature review, inspiration, and reproduction use cases for longer research tasks. Use it when the volume of candidate material exceeds what you can screen by hand in an afternoon, not as a substitute for your eligibility criteria.

Screening is where a reading list becomes defensible. Cochrane recommends screening in stages and linking multiple reports of one study. In practice:

• Stage one: title and abstract. Apply your eligibility criteria quickly. Keep, reject, or mark uncertain.
• Stage two: full text. For the uncertain and the kept, check the full text against the same criteria.
• Deduplicate. The same paper often appears under slightly different records. Merge duplicates rather than counting them twice.
• Link reports. One study may have multiple reports. Group them so your list counts studies, not PDFs.

Zotero's Duplicate Items collection supports review and merging, which is a useful model for how to handle duplicates in any reference manager. The principle matters more than the tool: one study, one entry, with linked reports.

A reading list that lives only in a search history will not survive the semester. Organize it so it can be reused.

Zotero collections can place one item in multiple project groupings without duplicating it, and tags can describe topic, method, status, or workflow. That is a good design pattern even if you use a different tool: one canonical record, multiple groupings, and tags that carry meaning beyond topic.

For a January project start, a workable structure is:

• Core: sources you will definitely cite.
• Background: sources that frame the field but may not be cited directly.
• Method: sources that justify your approach.
• Watch: sources that are relevant but need a closer read.

Tags can mark status (to read, read, cited) and method (qualitative, experimental, review). Saved searches that update automatically are useful for keeping a watch list current without re-running everything by hand.

If you want a place to save and organize papers in one library, My Library lets you save or upload papers and organize them. Pair it with a project note that records your scope question and criteria, so the library has a purpose beyond storage.

A reading list is not finished when the papers are collected. It is finished when it can do work for you. Three artifacts make that happen:

1. The annotated list. Each entry gets a one-line note on why it is in the list and which part of your argument it supports.
2. The methods note. A short record of your search terms, sources, filters, and screening decisions. This is what makes the process transparent.
3. The citation set. The subset you will actually cite, with clean metadata.

For the methods note, PRISMA 2020 is a useful reference point even for a course paper. It provides a reporting checklist, expanded explanations, and flow-diagram templates for systematic reviews, including transparent reporting of search, selection, and synthesis methods. You do not need a full systematic review to borrow its discipline: report what you searched, how you selected, and how you synthesized.

When you are ready to ask questions across the papers you have collected, Library QA lets you ask questions based on papers uploaded to My Library or added from search results. That is useful for checking how a set of sources addresses a specific sub-question before you commit to citing them.

A reading list is only as good as its references. Before you hand the list to a supervisor or paste citations into a draft, screen the bibliography itself.

TrueCite checks BibTeX against real academic databases to flag hallucinated references. Run it on the citation set you plan to use. This is a concrete step, not a formality: a reference that cannot be matched to a real record is a problem you want to find before your reader does.

At the same time, check that each citation in your draft maps to an entry in your list. A citation that appears in the text but not in the list, or vice versa, is a sign that the list and the argument have drifted apart.

A reading list is ready when it passes a short readiness check. Use these criteria:

• Scope is stated. The scope question and eligibility criteria are written down and visible.
• Search is documented. Terms, sources, filters, and dates are recorded.
• Screening is staged. You can say how many records you screened at each stage and why you excluded what you excluded.
• Duplicates are merged. One study appears once, with linked reports grouped.
• The list is organized. Core, background, method, and watch groupings exist, with status tags.
• Citations are checked. The citation set has been screened against real records.
• The list does work. Each core entry has a note on what it supports in your argument.

If any of these is missing, the list is not ready. If all are present, you have a deliverable you can defend and reuse.

By the end of the repair, the January project has a reading list that looks like this: a project note with scope and criteria, a documented search plan, a screened and deduplicated record table, an organized library with status tags, an annotated core list, a methods note, and a checked citation set.

The transferable lessons are simple. Define scope before searching. Derive terms from criteria. Capture records as you go. Screen in stages and merge duplicates. Organize for reuse, not just for this week. Check citations before you commit. None of these depend on a particular tool; they are the structure that makes any tool useful.

Before Monday, write the scope question and eligibility criteria in a single project note. Then run one search from that plan, capture the records, and screen the first page. If you want a place to hold the project, Research Projects lets you create a new project in the WisPaper Research Projects area. Start there, and let the reading list grow from a documented plan rather than a folder of PDFs.