dsai-gate, a curated study repository, and the link checker that admits what it is

Seven topic files, and one directory that matters most

The repository is organised by exam syllabus, and that organising principle is the whole design. Seven topics, each with its own README file, and the syllabus itself is a linked PDF from the exam's organising institute for the 2027 paper.

The topics are probability and statistics, linear algebra, calculus and optimization, programming and algorithms, database management, machine learning, and artificial intelligence. Each description in the README's own table gives a sense of depth: vector spaces, matrices, eigenvalues and singular value decomposition under linear algebra; ER models, relational algebra, SQL and normalisation under databases; search algorithms, logic, reasoning and uncertainty under artificial intelligence.

Seven files for a two-year engineering entrance examination is a reasonable scope, and it is the shape a syllabus has rather than the shape a learner has. Nobody studies a syllabus linearly. The split into probability, linear algebra, calculus, programming, databases, machine learning and artificial intelligence corresponds roughly to how a preparation plan allocates weeks, and the topic list in the README's own structure table maps each one to a file.

The directory that matters more than any of them is the previous-year-questions one. For a competitive examination, past papers are the highest-value material in existence, because they tell you the distribution of questions, the depth expected, the notation used, and the traps. A repository that collects them in one place has done something a list of recommended textbooks cannot. The deployment workflow description says the site rebuilds when the topics, notebooks, resources, previous-year-questions or webapp files change, which tells you the questions are a maintained part of the site rather than an afterthought.

The rest of the tree supports the curation. There is a notebooks directory, which is why the repository's primary language is recorded as Jupyter Notebook rather than Markdown. There is a resources index file, a topic resources directory, an interview directory, a data directory, a documentation directory, a scripts directory, and a webapp directory that is the interactive explorer and memory map.

And at the top level there is a Python script whose name is the most honest thing in the repository: a link checker. A resource collection is a set of links, links rot, and a project that ships a script to find the broken ones is telling you exactly what kind of project it is.

The Unlicense, and what it covers when the content is other people's

The licence is the Unlicense, which is worth understanding precisely because it is the most permissive grant in common use and because this repository's content is mostly not its own.

The Unlicense is two things stacked. The primary one is a dedication: the author waives all of their copyright and related rights and places the work in the public domain. The fallback is an unrestricted licence, in the permissive tradition, so that jurisdictions which do not recognise a public domain dedication still have explicit permission to do anything with the work. The practical effect is that there are no conditions at all. No attribution required, no share-alike requirement, no notice to preserve.

For a software project that is a strong choice, and it is the one to use if you want maximum adoption. For a resource collection it is also the most honest choice available, and here is why.

Almost everything this repository points at belongs to somebody else. The section format it describes includes courses from a national online learning platform, books, articles, practice problems from commercial interview sites, and tutorial sites. The author did not write those, and cannot grant rights to them, and pretending otherwise with a copyleft licence would be a false claim. What the author actually authored is the curation: the selection, the filing against a syllabus, the summaries, the notebooks and the site.

So the Unlicense covers the curation and nothing else. A reader who downloads a notebook has no restrictions on it. A reader who follows a link to a textbook is subject to that textbook's terms, not this repository's. And a forger who takes the whole structure and the selection, removes the attribution, and republishes it as their own guide has done nothing the licence forbids, because the licence asked for nothing.

That is the real cost, and it is a deliberate choice rather than an oversight. Most educational repositories use a Creative Commons attribution licence precisely so that a fork must credit the original. This one has decided that being a map is not authorship worth protecting, which is either admirable or a missed protection, depending on what you think a curated list of links is.

There is one more thing the licence does not cover, and it is the thing an exam candidate most needs to know. The syllabus PDF it links to, the past question papers, and the recorded courses are all third-party documents with their own terms, and a repository that is public domain does not make its contents so.

The explorer, the memory map, and a deployment with one manual step

The GitHub Pages site carries two things beyond the documents, and the deployment description for both is unusually specific.

There is an interactive syllabus explorer, and there is an overall memory map. For a collection of this kind those are the two features that turn a pile of links into something navigable, because the problem with seven topic files is that a learner does not arrive knowing which topic a question belongs to. An explorer that presents the syllabus and lets you drill into the material for each part solves the discovery problem. A memory map is the more unusual of the two: it is a visual representation of how the topics relate, which for an exam spanning probability, linear algebra, programming and machine learning is a real question, since those are usually taught as four disconnected courses.

The deployment description reads like a delivery note rather than a feature list, and it is more useful for that. There is a GitHub Pages workflow file. It tests and builds on pull requests, so a pull request that breaks the site is caught before it merges. It deploys automatically after merging to the default branch. It rebuilds when the topics, notebooks, resources, previous-year-questions or webapp files change, which is the set of paths that affect the site, so a documentation-only change does not consume a deployment. It uses current GitHub Actions versions, which is worth noting because pinned-to-an-old-version actions are a common cause of deployments that silently stop working.

And then the one manual step, which is the kind of detail that costs a first-time deployer an hour: in the repository settings, the Pages source has to be set to GitHub Actions once. The README also says the workflow was verified along with the tests and the static export, which is a small claim of testing that a documentation repository would not normally make.

Adding deployment status and app links to the README automatically is a nice touch, since the README then always points at the current deployment rather than at a URL somebody pasted in a year ago.

The section format, and why Interview belongs in an exam repository

Each topic README follows the same structure, and the format is specified in the main README so that every contributor produces the same shape. It is seven sections, in this order:

  Each Subsection-Readme is organised in the following format:
  [Table of Contents]
  * Books
  * NPTEL and Courses
  * Notes
  * Articles
  * Programming : Examples and tutorial such as Kaggle for ML, GFG for Python and Algo
  * Practice Problems
  * Interview

The ordering is sensible and it is a learning sequence rather than a taxonomy. Books are the reference layer. University courses are the systematic layer, and naming a specific national platform is a deliberate steer toward material with a fixed curriculum rather than a random video. Notes are the summarising layer. Articles are the depth layer. Programming is the hands-on layer, with a commercial data-science competition site named for machine learning and a commercial coding-questions site named for Python and algorithms. Practice problems is the drilling layer.

Then there is Interview, and it does not belong in an exam preparation repository. Nothing about a two-year engineering entrance examination is an interview, and a candidate using this for its stated purpose will not open that section.

Its presence is explained by a sentence elsewhere in the README, which describes the repository as a preparation-to-interviews guide as well as an exam resource. So the repository has two audiences with two different needs and one file structure, and the section format is the compromise. That is a defensible decision for a volunteer project trying to be useful to as many learners as possible, and it has a cost: a repository with two audiences optimises for the one that keeps contributing, and the interview-oriented sections are easier to add material to than the past-paper archive.

The README still contains its own template instructions

There are two HTML comment blocks sitting inside the README, and they are the most revealing thing in the file.

The first is a template instruction that was never removed. It tells the owner to replace four placeholder values, a link to notes, a name, a link to contact and a link to discussions, with the actual URLs for the repository, and to validate the contributor's tag for each subject. Those are instructions from a repository template, left in place, and they are visible in the rendered README as nothing at all because HTML comments do not render. So a reader never sees them and a contributor never sees them, and they tell you the README was generated from a template and lightly edited.

The second block is different in kind, because it is not a template. It is a planning comment with real names and a real to-do list in it: a week in late August, an assignment of machine learning and optimization to one person, artificial intelligence and probability statistics to another, linear algebra to a third, and then the open questions. How to put interactive assignments in. Need more reviewers. Find more people from a collaboration. Slides, preferably standard.

That comment tells you the state of the project more accurately than any section of the rendered README. There is an interactive-assignments feature planned, the reviewer base is a named handful of people, and the slide format is undecided. And the README's own banner says the project is still a work in progress looking for solid contributors, with a contributors guide in the wiki.

There is nothing wrong with a repository containing its own planning notes, and leaving them in is arguably more useful than pretending the plan is settled. But the practical consequence is that the rendered README describes a more complete resource than the repository is, and a reader cannot tell from the front page which parts are finished. A one-line status per topic would fix that, and the structure table is already the right place for it.

The other thing visible in the front matter is a mismatch of identity. The pull request badge and the site deployment badge both point at a different repository, under a different account, from the one hosting the README. That is the most common defect in this class of project and it is worth naming as a pattern rather than a criticism of this one.

Badges pointing at the previous owner, which is the standard defect here

Three badges in the README's header point at a repository under a different account from the one you are reading, and one of them is a workflow status badge for the site's deployment.

The pull request welcome badge links to the pull requests page of a repository with a different name and a different owner. The site deployment badge links to a workflow status page of that same other repository. So the badge claiming to show whether the site builds is reporting the build status of a different project entirely.

This is a specific and very common failure mode in a class of repository: one that is created, developed, and then donated or transferred to an organisation. The badges keep the original owner's URLs because the markdown was written before the move and nobody revisited it. The result is worse than a missing badge, because a broken badge is visibly broken and a stale one is silently wrong. A reader sees a green build badge and concludes the site is healthy.

The same drift shows up in a second place. The repository lives under one organisation, and the hosted site is published from a different path than the repository it is built from, with a third name in the documentation links. The front page offers a link labelled as the project site, and the deployment description talks about a workflow file and a Pages URL that are consistent with each other but not obviously with the repository you are in.

None of this affects whether the material is good. The links to the seven topic files are relative, so they work. The resource links inside them are absolute, so they are unaffected by any rename. What is affected is trust in the front page: a repository whose badges point elsewhere, whose site path does not match its repository, and whose contributor guide is in a wiki under a third name, is asking the reader to do a small amount of verification before trusting anything else it says.

For a community project this is a documentation chore rather than a defect in the work, and it is fixable in ten minutes by regenerating the badge URLs. Not fixing it is what tells you how much attention the project has.

Editorial conclusion

Use this repository as a map of the GATE data and AI syllabus rather than as a course, because the value is that everything is filed against a published syllabus document and that the previous-year questions are collected in one place, which is the part you cannot easily assemble yourself. Do not treat the linked courses and books as covered by its licence, because the Unlicense applies to the curation and not to third-party material it points at. Verify first by reading the previous-year-questions directory to see whether the collection is current for the exam year, opening the Pages site to check that the explorer matches the current syllabus rather than the previous one, and running the link checker script, whose existence tells you how much of the curation is still accurate.

Frequently asked questions

Official sources

1. DS-AI-GATE/dsai-gate on GitHub
2. Issues
3. License: Unlicense
4. Project website
5. README