GuangLun2000.github.io: a Minimal Mistakes Jekyll site for academics

What the repository actually is

The README opens with the name. GuangLun means Nimbus in Chinese, and the site belongs to Hanlin Cai, also known as Lance, and the repository is described as the source for his personal website.

The description in the repository metadata gives the lineage. It is a minimalism style site powered by Jekyll, based on the Minimal Mistakes theme and on Jason Ansel's website. The statement at the end of the README repeats the same chain: published with GitHub Pages, powered by Jekyll, based on the Minimal Mistakes theme and Jason Ansel's site.

So there are three layers. Jekyll is the static site generator, Minimal Mistakes is a well known Jekyll theme, and Jason Ansel's site is the original source of the layout and the content structure that this repository adapts. The October 2022 news entry records that this GitHub Page was built based on Jason Ansel's site, and the December 2022 entry records that the personal site itself was implemented at the author's own domain.

The licence field on the repository records MIT, and the primary language is listed as CSS, which is consistent with a theme-derived site where the bulk of the code is styling rather than logic. The topic tags describe the shape: academic-website, blogs, github-pages, jekyll, minimal-mistakes-theme, minimalism, pages, personal-blog, personal-website, publications and website-theme.

It is worth being clear about what this is. It is a personal website, with a personal name, a personal photograph and a personal history. Its value to other people is that the structure is complete and documented enough to fork.

Deploying a copy, and where the settings go wrong

The deployment section is the most practically useful part of the README, because it covers the two cases that Jekyll users get wrong.

First, fork the repository to your own GitHub account, or create a new repository and push the files.

Then choose a URL, and this is where the two cases diverge. For a user or organisation site at https://username.github.io, rename the repository to username.github.io and leave baseurl unset, as this repository does. For a project site at https://username.github.io/repo/, keep any repository name and add baseurl set to the repository name, plus the url set to the user's GitHub Pages address, both in _config.yml.

That baseurl distinction is the classic Jekyll on GitHub Pages failure, because the templates generate links from it and a site with the wrong baseurl produces links that 404 on every page except the root.

Then edit _config.yml to set the url, title, tagline, description and owner, where the owner block carries the name, the avatar, the email and the social links. A custom domain is optional: put the domain in the CNAME file, or remove that file if you only use the github.io address, and point the DNS at GitHub as the GitHub documentation describes.

Finally, turn on Pages in the repository settings. Under build and deployment, choose to deploy from a branch, set the branch to main and the folder to the root, then save and wait for the first build, which usually takes a few minutes.

A deeper walkthrough including local preview with Ruby and Jekyll lives on the author's blog, and the README points there for that.

The content structure of an academic site

The repository root is where the site's shape becomes visible, and it is a good checklist for what an academic website needs.

There is _config.yml and the standard Jekyll directories _includes/ and _layouts/, plus an assets/ directory and an images/ directory. There is a CNAME file for the custom domain, and a .gitignore.

The content pages are the interesting part, and they are plain Markdown files at the root rather than a collection under a posts directory. There is index.md as the front page, publications.md for the publication list, awards.md for the awards and honours, services.md for the service and teaching roles, hobbies.md, and blogs.md which is the blog listing. There is a cn.md, which is the Chinese version of the front page, and a blogs/ directory holding the posts, plus a mypaper/ directory for the papers themselves and a backup/ directory.

The personal assets are at the root too, a jpg for the profile photo and a png for a logo.

Two things are worth copying from this layout. The first is that a publications page with a dedicated papers directory is how an academic site should be structured, rather than a list of links to PDFs hosted elsewhere. The second is the bilingual front page, with the Chinese version as a separate top level file, which is a simple way to serve two audiences without a full internationalisation layer.

The project also carries a history in its news entries, which is a good model for a personal site: a note of when the repository passed 500 stars in September 2024, when video tutorials on building a Jekyll site were uploaded to Bilibili in May 2023, when the full building guide was posted in April 2023, and when the personal domain was implemented in December 2022.

Where this repository is the wrong choice

The first limitation is that it is a personal site with a personal name in it. Forking it means removing a name, a photograph, a logo, a publications list and a history, and what is left is a theme with some pages. Anyone who wants a personal site for themselves gets a good starting point; anyone who wants a template gets a site with a person in it that has to be surgically cleaned first.

The second is that the content is in English and Chinese in a way that only suits one person. The Chinese front page and the Chinese tutorial videos are tied to a single author's audience, and the internationalisation is a pair of files rather than a locale system, so a site needing three or four languages has to build that.

The third is the build system. Jekyll means Ruby on the build machine, a Gemfile and a plugin set that has to keep working with the theme's pinned versions, and a build step that GitHub Pages runs for you only if the plugin set stays inside what Pages allows. A team that already has a static site pipeline, or that wants a content management system so a non-programmer can write, is better served elsewhere.

The fourth is that there is no search, no comments and no analytics, which is a defensible set of omissions for a minimal site and a problem for a site with an archive large enough to need one.

The fifth is the theme lineage. The design comes from Minimal Mistakes and from Jason Ansel's site, and the CSS that dominates the repository is inherited rather than original. That is fine for a personal site and is worth knowing if you plan to contribute design changes upstream, since the upstream themes have their own maintainers and their own release cycles.

How it compares with the Minimal Mistakes theme alone and with a Hugo academic site

The comparison with the Minimal Mistakes theme by itself is the first one, and the difference in approach is content structure. The theme provides layouts, a documentation-style home page, tags, authors, comments and a look; this repository adds the pages that an academic needs, the publications list, the awards list, the papers directory, the services page and the Chinese front page, wired into the theme's conventions.

So if you want a personal blog, the theme is the better starting point because it is maintained as a project with releases and documentation. If you want an academic site, this repository saves you from working out where a publication list belongs and how to keep the PDF files in the repository rather than on a personal drive.

The second comparison is with a Hugo academic site, and the trade is between ecosystem and build speed. Hugo is a single binary with no Ruby dependency and builds a large site in seconds, and the academic community has a well-known theme for it. Jekyll has a deeper plugin ecosystem and is what GitHub Pages supports natively, so a site that must be built by GitHub itself rather than by your own CI cannot use Hugo without a build step of its own.

The third comparison is with a plain markdown site generator, and the difference is theme and features. The point of starting from a theme is that the navigation, the tags, the search and the responsive layout are already solved, and a static site generator on its own leaves you writing all of that.

Licence, maintenance and what to check before you fork it

The licence field on the repository records MIT, with a LICENSE file at the root, and the statement at the end of the README attributes copyright to Hanlin Cai. A permissive licence is the right one for a template, since it lets anyone fork, modify and deploy as long as the copyright notice is kept.

The project is not archived and the last push was on 2026-10-20, so the site is being worked on, and the recent releases section says there are no GitHub releases, which is normal for a website repository whose deployments are the releases.

There is a.github/ directory, which is where the deployment workflow and any repository settings live, and the CNAME file at the root is the one file that has to change first if you use a custom domain rather than a github.io address.

Three things to check before you fork it.

That you set both url and baseurl correctly for the kind of site you are deploying, since that is the difference between a working site and one whose every internal link is broken.

That you have Ruby and Jekyll available if you want to preview locally, since the README points to the tutorial for that and GitHub Pages will build without them but you will not see changes until you push.

And what you keep. The name, the photograph, the logo, the publication list and the awards page are one person's record of their work, and the site is a much better starting point once those are removed and your own are in their place.

Editorial conclusion

GuangLun2000.github.io suits a researcher or student who wants a clean academic website with publications, awards and a blog, and who is comfortable with Jekyll and GitHub Pages. It is the wrong tool for a team site, for a site that needs a content management system, and for anyone who wants a build that does not depend on Ruby and on a static site generator. Before forking it, read the deployment steps in order, because the baseurl and url settings are the part people get wrong, and note that the author is explicit that the README is the reference while a longer guide lives on the blog.

Frequently asked questions

Official sources

1. GuangLun2000/GuangLun2000.github.io on GitHub
2. Issues
3. License: MIT
4. Project website
5. README