graph-based-deep-learning-literature: a conference index you read on GitHub, not install
links to conference publications in graph-based deep learning
At a glance
- What is it?
- This repository is a curated set of links to graph-based deep learning papers, sorted by conference, year and topic, plus workshops, surveys and software lists. The judgement: it is useful for survey work and for tracking where a subfield publishes, but it is a reading list, not a library, and it carries no code you can run.
- Who is it for?
- Adopt it if you need a pre-sorted entry point into graph-based deep learning venues, or if you are building a reading group list and want the conference and year already separated. Do not adopt it if you need runnable code, dataset loaders, or anything that tracks papers outside the listed conferences and years.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 100 days ago.
- What is it written in?
- Mainly Jupyter Notebook, according to GitHub's language statistics.
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 the repository actually is, and what it is not
The README opens with a plain statement: the repository primarily contains links to conference publications in graph-based deep learning. That is the whole product. There is no package, no importable module, no dataset, and no evaluation harness. The primary language is listed as Jupyter Notebook, but nothing in the supplied material describes a notebook that runs an experiment. Treat the language field as metadata about the file mix, not as a promise of executable content.
The target reader is someone who needs to find papers rather than run them. A PhD student mapping a subfield before writing a related-work section. An engineer asked to evaluate whether graph neural networks apply to a problem, who wants the last three years of NeurIPS and ICLR entries in one place. A reading group picking a paper a week. For those people the value is in the sorting, not the content.
What it is not: a maintained implementation, a benchmark suite, a leaderboard, or a substitute for a literature search engine. If you need to reproduce a result, the link takes you to the paper, and the paper takes you to whatever code its authors released, if any. This repository does not intermediate that step.
How the link collection is organised: conference, year, then topic
The structure is a two-level index. The top level groups venues into categories, starting with Machine Learning Conferences (NeurIPS, ICML, ICLR) and Data Mining Conferences (KDD), and the README also points to Related Workshops, Surveys / Literature Reviews / Books, and Software / Libraries as sibling lists.
Under each venue, the README lists years as separate links. NeurIPS runs from 2025 back to 2015, with everything older than 2017 collapsed into a single 2017_and_Earlier file. ICML runs 2026 back to 2016. ICLR runs 2026 back to 2014. KDD is listed for 2025 and 2024 in the material provided. Each year link resolves to a README inside a folder path of the form conference-publications/folders/years/<year>/publications_<venue><yy>/README.md, so the naming is mechanical and predictable: publications_neurips25, publications_icml26, publications_iclr26, publications_kdd25.
The README states that within each conference and year, publications are organised into topic-specific categories. That is the part that saves time. A flat chronological dump of a conference would force you to scan everything; a topic split lets you read only the categories relevant to your question. The trade-off is that the category scheme is the maintainer's, and the material does not describe how categories are defined or how a borderline paper is assigned.
Getting to the papers: no install, just paths
There is no installation step, no dependency file, and no configuration key anywhere in the supplied material. Usage is navigation. The README gives the top-level entry point as conference-publications/README.md, which is the file that anchors the conference list.
From there the pattern is consistent enough that you can construct a path by hand. If you want ICLR 2023, the README links to conference-publications/folders/years/2023/publications_iclr23/README.md. For NeurIPS 2024 it is conference-publications/folders/years/2024/publications_neurips24/README.md. The older material is the exception: NeurIPS 2015 and 2016, ICML 2016 and 2017, and ICLR 2014, 2016 and 2017 all live inside conference-publications/folders/years/2017_and_Earlier/README.MD, addressed by anchor fragments such as #neurips-2017 or #icml-2016. Note the file extension on that one: README.MD in uppercase, unlike the lowercase README.md used elsewhere. If you are scripting against these paths, that inconsistency will break a naive glob.
The practical workflow is to clone the repository and grep it, or to read the per-year README in the browser. Because the content is Markdown links, a local clone plus ripgrep over the conference-publications directory gives you a searchable index of titles and URLs. The repository does not ship that tooling; you would be writing it.
Coverage is bounded by the venue list, and that is the main limitation
The index only contains what the maintainer has chosen to index. The README names NeurIPS, ICML, ICLR and KDD in the material supplied, with the truncation cutting off mid-list at KDD 2023. Venues outside that set, and journals in particular, are not represented in what is described. If your subfield publishes mainly in JMLR, TMLR, or domain venues, this repository will look sparse to you, and the sparsity reflects the scope rather than the state of the field.
A second limit is freshness. The README lists future years, including ICML 2026 and ICLR 2026, which means the links exist ahead of or around the publication cycle. Whether a given year file is complete or partially filled at any moment is not something the README states. The last push timestamp on the repository is 2026-06-07, so the index is being touched, but the material gives no per-year completeness signal.
A third limit is that links rot. This is a link collection with no archived copies and no DOI resolution layer described. When a paper page moves or a proceedings URL changes, the entry becomes a dead link, and the only fix is a pull request. There are no releases retrieved for this repository, so there is no versioned snapshot you can pin to and no changelog describing what changed between states.
Where it sits against Papers with Code and Semantic Scholar
The obvious alternatives are automated indexes. Papers with Code associates papers with implementations and links to code repositories directly on the paper page. Semantic Scholar provides citation graphs, author pages, and recommendation feeds. Both are search-first: you type a query and get ranked results.
This repository inverts that. It is browse-first and human-curated, organised by venue and year rather than by relevance score. The difference matters in two concrete ways. First, a curated conference list will not surface a paper you did not know to search for, but it also will not miss a paper because the ranking buried it. Second, the venue-and-year axis answers a question automated indexes handle poorly: what did this specific community publish in this specific cycle. If you are preparing a submission and want to know what the field looked like at the last edition of the conference, that axis is the point.
The cost of the curated approach is coverage and latency. An automated index picks up a paper when it appears on arXiv; a curated list picks it up when a human adds it. The material does not describe any automated ingestion, so assume the latter.
Maintenance, contribution and the MIT licence
The repository is licensed MIT and is not archived. MIT is permissive: it allows reuse, modification and redistribution with the licence text retained, and it comes with no warranty. The licence applies to the repository contents, which here are the README files and their organisation. The papers themselves are not covered by this licence, and neither is any code those papers link to. If you plan to copy the category structure or the link lists into your own index, the MIT terms are what govern that reuse. This is a description of the licence text, not legal advice.
Maintenance is the real cost, and it is borne by whoever wants the list to stay current. Adding a paper means editing the correct per-year README under conference-publications/folders/years/<year>/publications_<venue><yy>/, placing the entry in the right topic category, and opening a pull request. Nothing in the material suggests an automated pipeline, a schema check, or a link validator, so a malformed entry or a dead URL is caught by a reader, not by CI.
For a consumer, the ongoing cost is re-checking. Because there are no releases, you cannot say "I used the 2026.1 snapshot." You either clone and pin a commit hash yourself, or you accept that the list you read today may differ from the list next month. For a reading list that is usually fine. For anything you intend to cite as a fixed corpus, pin the commit.
Workshops, surveys and software as separate entry points
Three of the sibling lists are worth calling out because they serve different jobs than the conference index. The Related Workshops list is where you look for work that is early or niche enough not to have cleared a main track. The Surveys / Literature Reviews / Books list is the one to check before you start reading primary papers, since a survey can save you the pass entirely. The Software / Libraries list points at implementations, which is the closest this repository comes to being useful for someone who wants to run something, though it is a list of links and not a dependency manifest.
The software list is also the weakest of the three in terms of what the material tells us. The README links to conference-publications/folders/software/README.md but does not describe how libraries are selected, whether they are maintained, or what they cover. If you arrive from a search looking for a graph neural network library, that page is a starting point for further reading, not an evaluation.
The surveys list has the same property: it points, it does not summarise. Neither list carries the kind of metadata (last commit, licence, supported framework) that would let you pick between two libraries without leaving the repository.
Editorial conclusion
Adopt it if you need a pre-sorted entry point into graph-based deep learning venues, or if you are building a reading group list and want the conference and year already separated. Do not adopt it if you need runnable code, dataset loaders, or anything that tracks papers outside the listed conferences and years. Before relying on it, open the README for the specific year folder you care about and check whether the entries you expect are present, since the coverage is per conference and per year rather than comprehensive.
Community notes