best-of-digital-gardens is a scored index of public notes, and the score is the argument

One entry per garden, filtered by a specific technical condition

The list has a narrower definition of digital garden than the term usually gets, and that definition is the first thing to check. A project qualifies if it shares the source of its content as a git repository, which excludes the majority of gardens that are static site generators writing to a published branch or a page builder with a private source. The description also states the collection holds 100 gardens with a total of 4K stars, and that they are grouped into categories. The categories are Activism, with Feminism and Antifascist subcategories, Programming with a Python subcategory, Quality Assurance, Productivity, Health, Arts and Science. So the list is a discovery index for reading, not a directory of software to install, and the entries are websites with a public source, ranked by a computed score rather than curated by hand.

The score is computed, and its components are all visible

Ranking is described as a project quality score calculated from various metrics automatically collected from GitHub and different package managers, and the explanation section lists the components. The first is a combined project quality score, shown with medal markers for the top three. Then come the raw signals: star count from GitHub, contributors count from GitHub, fork count from GitHub, issue count from GitHub, and the last update timestamp on the package manager. Alongside those are derived states. A project is flagged as new if it is less than 6 months old, as inactive if it has had no activity for 6 months, and as dead at 50 months with no activity. Arrows indicate whether a project is trending up or down, and a plus marker shows a project that was recently added. Because the metrics are public, you can recompute or contest any ranking yourself, and because the thresholds are stated, an inactive marker on a personal site says more about the author's publishing rhythm than about the quality of the notes.

The English section shows what a good entry looks like

The rendered list shows a concrete shape for an entry. The first one visible under English is the Wayanjimmy Notebook, presented with a combined score of 9, a star count of 30 and an inactive marker, followed by a row of category icons for tools, programming, science and time management, and a link to its GitHub repository with contributor, fork and package manager update details. Memento follows with a combined score of 4 and an inactive marker, tagged across programming, Linux, Python and tools. Oscean appears with a score of 2 and no activity metadata at all, and the Xinyang YU entry shows a much larger contributor count. Craft Engineer is described in prose as a digital garden focused on engineering management, software development and personal growth. Two things are apparent. The icons let you slice the list by theme rather than reading it top to bottom, and the metadata richness varies, so some entries carry an update timestamp and others carry nothing.

Updates are automated, and the repository shows the machinery

The README describes the list as updated weekly, and the repository layout shows how that happens. There is a .github/ directory, and a badge points at an update workflow in the separate lyz-code/autoimport repository, which is where the collection of metrics and the regeneration of the ranking live. The .clean_readme.sh script at the root is the piece that turns the collected data into the rendered README, which is why the primary language of this repository is recorded as Shell rather than Markdown. The config/ directory holds the settings, history/ keeps the record of previous states, and latest-changes.md tracks what moved between updates. The consequence for a reader is that the list is not a document someone curates by reading the gardens, it is a report produced by a pipeline, and the pipeline is the thing to look at if you want to know why something ranked where it did.

Adding a garden means editing a YAML file, not writing prose

The contribution route is unusually low friction, and all three paths are described in the README. You can open an issue, you can submit a pull request, or you can directly edit projects.yaml, which is the file where the list of projects lives and which the README links directly to an editing view on the main branch. Contributions are explicitly welcomed. This is a different relationship from a traditional awesome list where the entry is a hand-written markdown bullet with a description someone had to compose, and it is also a different relationship from a directory site where the submitter fills a form and a moderator writes the copy. Here the metadata is the content, so the quality of the entry depends on what the project itself exposes on GitHub and in its package manager rather than on the submitter's writing. The trade-off is that the descriptions, where they exist, are inconsistent, as the Craft Engineer entry shows, because some submitter wrote one and others did not.

What a list like this cannot tell you

There are limits that follow from the design, and they are worth naming before you treat the ranking as a guide. The metrics are all activity and popularity signals, so a garden maintained obsessively by a single person and a garden maintained casually by a group can produce similar scores for very different reading experiences, and the score cannot see writing quality at all. The inactive and dead markers are activity thresholds, so a personal garden that posts twice a year and is excellent is marked the same way as one abandoned in the same month. The git repository requirement means genuinely excellent gardens built with a closed or non-git publishing workflow are invisible to the list. And because the entries point at sites rather than exporting their content, the list gives you a starting point and a score, and then you have to go and read the thing yourself. A curated list in which a human read each garden and wrote what it is good for would answer a different question, better, for a smaller set of entries.

Editorial conclusion

best-of-digital-gardens suits readers looking for a public second brain to read, and it suits people who want their own notes to appear in a discovery index, since adding a project means editing projects.yaml. It does not suit anyone who needs a tool rather than a list, because nothing here is software you run, and it does not suit you if a metric-based ranking is what disqualifies a garden you like. Before using it, browse the English section once to see how the score relates to what you actually enjoy reading, check the .github/ workflows to understand how often the ranking is recomputed, and add your own project through a pull request against projects.yaml.

Frequently asked questions

Official sources

1. Issues
2. License: CC-BY-SA-4.0
3. lyz-code/best-of-digital-gardens on GitHub
4. README