Open-source project
fregu856/papers avatar
fregu856/papers

fregu856/papers: A Nine-Year Reading Log With Annotations, Not a Software Project

I categorize, annotate and write comments for all research papers I read (550+ papers since 2018).

417 stars55 forksUnknownLicense varies

At a glance

What is it?
This repository is one researcher's chronological index of 550+ papers read since 2018, each entry carrying a category tag, a link, and a short personal comment. It is useful as a model for how to keep a reading log, and as a source of pointers into computer vision, ML for healthcare, and drug discovery literature. It is not a library, a tool, or a dataset.
Who is it for?
Adopt the format, not the repository, if you are a graduate student or researcher who reads papers steadily and wants a low-friction record you can search by year and topic. Do not expect a maintained index: entries are appended as reading happens, categories are the author's own, and the 2026 entries show the log drifting into blog posts and non-open-access papers with no annotated PDF.
Can I use it commercially?
Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
Is it still maintained?
Yes. The repository last received commits 7 days ago.
What is it written in?
GitHub does not report a main language for this repository.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

What fregu856/papers actually is, and who it is for

The README opens with a single sentence of scope: the author categorises, annotates and writes comments for all research papers read, 550+ papers since 2018. That is the whole product. There is no installable artifact, no package manifest, no build step, and no source code in the sense an engineer would expect. The repository is a Markdown file plus a commented_pdfs directory holding annotated copies of papers the author was able to obtain openly.

The intended reader is not a software team. It is someone who wants to see how another researcher organises a long reading habit, or who wants a curated entry point into a specific subfield. The category list is the strongest signal of who this is for: Uncertainty Estimation, Ensembling, Stochastic Gradient MCMC, Variational Inference, Out-of-Distribution Detection, Normalizing Flows, Object Detection, 3D Multi-Object Tracking, Neural Processes, Neural ODEs, Implicit Neural Representations, Distribution Shifts, Computational Pathology, Survival Analysis, ECGs, EHRs, ML for Drug Discovery. That is a machine learning researcher's reading list, weighted toward probabilistic methods, 3D perception, and clinical applications, not a general AI curriculum.

The author also links a June 2023 blog post titled The How and Why of Reading 300 Papers in 5 Years, described as covering why reading many papers matters, how the reading is organised, paper statistics, and a list of 30 particularly interesting papers. If you want the method rather than the index, that post is the intended companion.

The entry format: date, identifier, venue, category, comment

Every entry follows the same shape, and the shape is the point. A heading carries a date and a sequential paper number, for example [26-09-08] [paper579]. Below it sits the paper title as a link to the PDF, sometimes with a second link to an annotated PDF hosted either on Google Drive or in the repository's commented_pdfs folder. A code-formatted line gives the venue and year, such as `ICLR 2026` or `Nature Medicine, 2026`. A bracketed line gives one or more categories. Then a fenced code block holds the author's comment.

The numbering is global and monotonic across years, which means paper579 and paper572 sit in the same 2026 block. That is a deliberate choice: the number is a reading counter, not a within-year index. The date prefix uses a two-digit year, so 26-09-08 means 8 September 2026. Anyone parsing this file programmatically should treat the numbering as an append-only log rather than a stable identifier, because nothing in the material suggests numbers are ever reused or renumbered.

The comments are short and evaluative rather than summarising. On a Nature Medicine pathology foundation model entry, the author writes that slide-level vision-language models are interesting and that prompt-based inference directly at slide level could be useful, then questions how well report generation and open-ended Q&A can be expected to work given that Phi-3-Mini is a relatively small LLM. That is a specific, falsifiable opinion attached to a specific paper. It is the reason to read this repository rather than a citation manager export.

The category taxonomy is hand-built and unevenly populated

Thirty-seven categories are listed at the top of the README. They are not a standard taxonomy. Some are method families (Normalizing Flows, Neural ODEs, Energy-Based Models, Graph Neural Networks). Some are task areas (Object Detection, 3D Human Pose Estimation, Visual Tracking). Some are application domains (Computational Pathology, ECGs, EHRs, ML for Drug Discovery). Some are closer to research questions (Out-of-Distribution Detection, Distribution Shifts, Selective Prediction). One is a critique category: Social Consequences of ML.

This mixing of axes is a real limitation for anyone hoping to browse by concept. A paper on uncertainty estimation for medical imaging could plausibly land in Uncertainty Estimation, ML for Medicine/Healthcare, or both, and the material does not state a rule for how multi-category assignment is decided. In the visible entries, multi-tagging does happen: the Nature Medicine pathology foundation model entry carries both [Computational Pathology] and [Vision-Language Models]. So the taxonomy is applied with judgement, not mechanically.

There is also a Miscellaneous bucket, which is honest but tells you the taxonomy has edges. If you are looking for a complete map of a subfield, this is the wrong instrument. If you want to see which papers one researcher considered worth filing under, say, Computational Pathology, it works.

What the 2026 entries reveal about how the log is maintained

The most recent block is the most informative about maintenance behaviour. It contains papers, but also blog posts. Two entries in the 2026 block are explicitly labelled as blog posts from a Substack, with the venue line reading `(Blog post, 2026-09)` and `(Blog post, 2026-07)`. The author acknowledges this directly: one comment says the item is a blog post and not a paper, but was included anyway. Another says the same, adding that it was less informative than the previous one.

That is a scope drift worth naming. The README's opening sentence says research papers. The practice includes long-form technical writing. For a reader, this is mostly harmless and arguably useful, but it means the 550+ count is not a count of peer-reviewed papers.

A second pattern is access. Several entries carry the note that the paper is unfortunately not open access, thus no annotated pdf. So the annotated_pdfs collection is not a complete mirror of the log. It is a subset conditioned on licensing. If your reason for coming here is the annotations rather than the comments, you should check coverage in your area of interest before assuming it exists.

A third pattern is cadence. The visible 2026 entries cluster in August and September, with dates like 26-08-19, 26-08-20 (twice), 26-08-23, 26-08-24, 26-08-28, 26-09-04, 26-09-06, 26-09-08. That is a burst of roughly ten entries in three weeks. The material does not show whether this is typical or a catch-up period, so treat the apparent density as an observation about these entries only, not a rate.

Getting it: there is nothing to install, only files to fetch

Because the repository is a Markdown document plus a PDF folder, adoption means cloning or downloading, not building. The default branch is master. A minimal fetch would be:

git clone https://github.com/fregu856/papers.git

If you only want the index and not the annotated PDFs, you can skip the clone entirely and read the README on the web, or pull the raw file:

curl -O https://raw.githubusercontent.com/fregu856/papers/master/README.md

Annotated PDFs live under commented_pdfs/ in the repository, and the README links to them with repository-relative paths, for example commented_pdfs/End-To-End%20Multimodal%20Pathology%20Foundation%20Model%20With%20Clinical%20Dialogue.pdf. Some annotated PDFs are instead hosted on Google Drive, which the README links with a drive.google.com/file/d/... URL. That means a local clone gives you only part of the annotation set; the rest depends on Drive links remaining live.

There are no configuration keys, no environment variables, and no command-line interface. The only configuration is your own tooling. If you want to search the log, grep works on the raw Markdown because categories appear as bracketed tokens:

grep -n "\[ML for Drug Discovery\]" README.md

That is the entire integration surface. Anyone evaluating this as software will find nothing to evaluate.

Limitations: no licence, no schema, no freshness guarantee

The repository metadata supplied here lists the licence as unknown and the primary language as unknown. For a collection of Markdown and PDFs that is not surprising, but it matters. The author's own comments and category assignments are the author's writing. The annotated PDFs are modified copies of third-party papers, and the README itself flags that some papers have no annotated PDF because they are not open access. That suggests the author is aware of the constraint, but it does not establish a licence for redistribution. If you plan to mirror the commented_pdfs directory or reuse the comments, that is the first thing to resolve, and it is not answerable from the material here.

Structurally, there is no schema. The entry format is consistent by convention, not enforced by anything. Dates use a two-digit year, venues are free text, and categories are bracketed strings that must match the category list exactly for a grep to work. A typo in a category name would silently drop a paper from search results, and nothing would catch it. There is no CI, no linter, and no test suite, which is expected for a reading log but worth stating plainly for anyone planning to parse it.

Freshness is also uneven by construction. Entries are added when the author reads something, so a category can go quiet for a long time while another fills up. The README lists a Papers Read in 2026 section through 26-09-08, and the last push recorded is 2026-09-09, so the log is current as of that date. Nothing commits the author to continuing.

Alternatives, and how the approach differs

The obvious comparison is a reference manager such as Zotero or Mendeley. Those store bibliographic metadata, attach PDFs, and generate citations. This repository stores none of that. There are no BibTeX entries, no DOI fields, no author lists, no abstracts. What it stores instead is a dated, numbered reading sequence with a personal judgement attached to each item. A reference manager answers what a paper is. This log answers what one reader thought of it and when they read it.

A second comparison is a public paper-commentary site such as Papers with Code or an OpenReview thread. Those aggregate many readers and attach code or reviews at scale. This is one person's view, which is both the weakness (no consensus, no coverage guarantee) and the reason it is legible: the comments are consistent in voice and standard across nine years, so you can calibrate against them. A Nature Reviews Drug Discovery entry comments that the paper was interesting but that the author expected more, and that the authors' critical, non-hype perspective is appreciated while some points seem basic. That kind of calibrated, mildly negative note is rare in aggregated review platforms.

A third comparison is the annotated-bibliography pattern used in some PhD programmes, where a student maintains a structured file of summaries. This repository is essentially that pattern, executed for nine years and published. The difference is that a formal annotated bibliography usually carries full citation metadata and a stated scope. This one carries a category tag and a comment, and its scope has quietly widened to include blog posts.

Maintenance cost and what to verify before you rely on it

The maintenance cost is borne entirely by the author, and the material shows what that costs in practice: a per-paper comment, a category assignment, a venue line, a date, and an annotated PDF when access permits. Across 550+ papers since 2018, that is a sustained writing habit, not a one-off export. If you copy the format, budget for the comment, because the comment is the only part that carries information you cannot get from a search engine.

For a consumer, the cost is verification. Before citing or relying on this log, check three things against the actual file. First, open the category list and confirm the category you care about has entries in the years you care about, rather than assuming the label implies coverage. Second, follow one annotated PDF link from a recent year and one from an older year, since the README mixes repository-relative paths with Google Drive URLs and the two have different failure modes. Third, read the comment on the paper you intend to act on, because the comments include reservations. The entry on the AstraZeneca five-dimensional framework paper is described as a direct follow-up to an earlier paper the author had read, which is useful context only if you know the earlier one exists.

On licensing, the position is simply unresolved in the supplied material. The repository lists no licence, the annotated PDFs are derived from third-party papers, and at least some papers are excluded from annotation because they are not open access. Reusing the author's comments and reusing the annotated PDFs are therefore different questions, and neither is answered here. Treat the comments as one reader's notes and the PDFs as a convenience collection, and check the source paper's own terms before redistributing anything from commented_pdfs.

Editorial conclusion

Adopt the format, not the repository, if you are a graduate student or researcher who reads papers steadily and wants a low-friction record you can search by year and topic. Do not expect a maintained index: entries are appended as reading happens, categories are the author's own, and the 2026 entries show the log drifting into blog posts and non-open-access papers with no annotated PDF. Before relying on it, open one entry from a year you care about and check whether the annotated PDF link resolves, then check whether the category you need is actually populated rather than listed.

Official sources

  1. fregu856/papers on GitHub
  2. Issues
  3. Project website
  4. README
Community notes

Community notes