# based.cooking: a Hugo recipe site where the contribution rules are the interesting part > A public domain collection of substantial traditional recipes, built with Hugo and a minimal theme, whose unusually strict submission guide tells you most of what this repository is. **LukeSmithxyz/based.cooking** — A simple culinary website. - Repository: https://github.com/LukeSmithxyz/based.cooking - Stars: 2,348 · Forks: 534 - Language: CSS - License: Unlicense - Published: 2026-10-07 · Updated: 2026-10-07 · Language: en - Canonical page: https://hysenlabs.com/projects/lukesmithxyz-based-cooking ## What this repository actually contains The site is a collection of user submitted recipes at based.cooking, and the repository is the site. That means there is no application to install and no service to run. Hugo compiles markdown into a static site, and the README names the theme it uses, which is the author's own minimal theme called lugo. The tree is correspondingly small: `content/` holds the recipes, `layouts/` and `static/` come with the theme, `config.toml` is the site configuration, `archetypes/` covers new content scaffolding, and `data/` holds the per-author metadata. There are also two example files at the root, `example.md` and `cinnaroll.md`, which serve as the model to copy and as a worked example respectively. GitHub reports the primary language as CSS, which reflects the theme rather than anything the recipes are written in. The site's content is markdown with YAML front matter, so if you are looking for a programming project here, this is not one. What is interesting is the structure and the rules. There are no releases, and the last push was on 2026-09-09 with the repository not archived. Scale: 2,349 stars, 534 forks, and 7 open issues. ## The submission rules are the actual documentation The README spends more words on how to contribute than on describing the site, and the rules are specific enough to be worth quoting closely. File placement and naming are mechanical. Recipes go in `content/`, file names use hyphens between words rather than underscores or spaces, and the file has to end with a newline in the unix fashion, which the README notes is automatic if you are on Linux. ``` content/ data/authors/your-name.json pix/chicken-parmesan.webp pix/chicken-parmesan-01.webp ``` The content rule is a definition of what belongs: a recipe has to be based, meaning good traditional and substantial food, with nothing ironic, meme-tier, hyper-sugary, or meat-substitute. Salt and pepper are called out as ubiquitous enough that they should not appear in the ingredient list. Tagging has its own conventions, including the advice to reuse tags that already exist rather than invent new ones. Two tags encode diet: `fasting` if the recipe has neither meat nor dairy, and `cheesefare` if it has dairy but no milk. Credit is handled through an optional JSON file per contributor, `data/authors/your-name.json`, which can carry a website, a general donation link, an email, and crypto addresses for `btc`, `xmr`, and `eth`. The README says to model it on the author's own file. So attribution is optional metadata rather than a required field inside the recipe. ## Image rules, which are the strictest part of the guide Images are where the README spends the most editorial energy, and it is blunt about wanting better photographs and about rejecting submissions. The technical requirements are modest: images live in `pix/`, they should be `.webp`, and they should be small, with roughly 100K suggested as the target. Each recipe can have one title image and, if genuinely necessary, additional instructional images numbered with two digits. Links to them begin with a slash. Stock images are explicitly disallowed; the requirement is a picture of the actual dish you made. Beyond the technical rules, the guide is a quality bar expressed as a submission filter. The README argues existing images are largely poor and invites contributors to shoot a dish themselves and submit a replacement, then adds an informal test for whether an image is good enough involving getting approval from someone in real life before submitting. It also states that submissions failing the listed rules will be closed and have to be resubmitted, and that the author is tired of fixing more than half of submissions. That last point is the one that matters for anyone considering a contribution. It is a single maintainer with strong opinions and a stated impatience, which is why there are only 7 open issues against a large contributor base. Reviewing the README against the site before you submit is the practical way to avoid a rejected pull request. ## The public domain license, and the credit it asks for anyway The license section is short and unusual in a good way. The site and all its content are in the public domain, and the README adds that submitting text or images waives any pretense of ownership over them. GitHub reports the license as Unlicense, which is the formal SPDX identifier for the public domain dedication, so the metadata and the text agree. In the same breath the README asks contributors to keep credit for what they wrote, recommending they add their own name at the bottom of a submitted page, and allowing donation and contact links alongside it. So the legal position and the social expectation are deliberately different: nobody owns the text, and you are asked to be credited anyway. This is worth understanding before you contribute, because it is not what most recipe repositories do. Elsewhere a recipe you contribute is typically under a content license the project owns, and your name is attached. Here your text enters the public domain while your byline stays attached through the `data/authors/` file. If you write original prose and want attribution, the mechanism exists; if you want to reserve rights, this is not the place to submit it. ## How this fits alongside other recipe sites There is a reason a repository like this gets 534 forks. Submitting a recipe by opening a pull request is a different proposition from filling in a web form, and for some people it is a better one. You get version history on the recipe, you can see the review discussion in public, corrections arrive as diffs rather than as a rewrite, and the whole collection is forkable. The trade is that the site has no search engine of its worth, no accounts, no ratings, and no structured data beyond what the theme renders from markdown. GitHub's own search over the repository is arguably the search interface. There is also no dietary filtering or nutrition information, which is where most dedicated recipe databases spend their effort. None of that is a criticism so much as a description of the shape. This is a reading collection with a contribution process, built by someone who wanted the recipes to be freely reusable and was willing to enforce a quality bar by hand. The architecture choice is the minimum viable one. Hugo with a small theme and no database means the site can be hosted almost anywhere, and the whole thing rebuilds from the repository. There is a `.github/` directory, so at least some automation exists, and `config.toml` plus `archetypes/` indicate the standard Hugo scaffolding rather than a custom build pipeline. ## Conclusion This repository is best understood as a piece of editorial policy expressed as a static site, and the README is unusually direct about what that policy is. Recipes have to be substantial and traditional, the image rules are the strictest part of the guide, and the license puts everything in the public domain while asking contributors to keep their name on what they wrote. There is no code here worth evaluating: Hugo and a small theme generate the whole site, and the fork count of 534 against 2,349 stars says people are contributing recipes rather than studying the build. If you want to submit something, the fastest route is to copy `example.md`, follow the filename and tag conventions exactly, and read the image guidance before you photograph anything, since that is where submissions most often get closed. ## FAQ ### What is based.cooking and who runs it? It is a recipe site at based.cooking where users submit recipes for credit, built with Hugo and the author's own minimal theme. The repository is the site: recipes are markdown files in `content/`, images live in `pix/`, and there is no separate application to run. ### How do I submit a recipe to based.cooking? Model your file on `example.md` and put it in `content/`, with hyphens between words in the filename and a trailing newline. Add tags, reusing existing ones, and include `fasting` if the recipe has neither meat nor dairy or `cheesefare` if it has dairy but no milk. Credit goes in an optional `data/authors/your-name.json` file. ### What license applies to recipes and images I submit to based.cooking? The site and its content are in the public domain, under the Unlicense. Submitting text or images waives any claim of ownership over them. The README still asks you to keep your name on a page you contributed, with optional donation or contact links, so attribution is encouraged even though rights are not reserved. ## Sources - [Issues](https://github.com/LukeSmithxyz/based.cooking/issues) - [License: Unlicense](https://github.com/LukeSmithxyz/based.cooking/blob/master/LICENSE) - [LukeSmithxyz/based.cooking on GitHub](https://github.com/LukeSmithxyz/based.cooking) - [README](https://github.com/LukeSmithxyz/based.cooking/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lukesmithxyz-based-cooking