I built Kotlin Digest to make it easy for me to keep up with the Kotlin and Android world — what's changing, what people are talking about — without doom-scrolling a dozen feeds. Every week it scouts the ecosystem — official blogs, library releases, conference talks, individual developer writing — and assembles it into a chapter-structured edition hosted on GitHub Pages. It's an early version, and I'm still figuring a lot out.

Chapters are ordered by a living Topic Bible: a scored, decaying keyword graph that reflects what the community is actually talking about right now. Topics trending hard this week appear first. Topics fading appear later, or disappear until the discussion picks back up.

The site is a static page. Your reading preferences — which chapters you want, which you don't, which keywords to surface or suppress — are stored in a browser cookie. Lose the cookie, lose nothing important. The default is the full magazine.

The whole thing is open source. The pipeline that generates it, the sources it draws from, the topics it tracks, and the site itself are all in one repository — github.com/cicerohellmann/kotlin-digest. Everything is a PR.

I prioritise primary sources. A primary source is someone writing their own thoughts: a developer publishing a post-mortem, a library author announcing a release, a conference speaker sharing what they learned, an engineer documenting a pattern they found in production. That's the raw signal I want — people forming opinions and sharing them.

I don't render newsletters, link roundups, or digest publications — including well-regarded ones. It's a deliberate choice, not a slight against the people who make them. Here's why it matters technically: the Topic Bible derives its scores from what I ingest. If I ingested a newsletter that had already curated this week's Kotlin news, the Bible would score what that editor decided was important — not what the community actually wrote about. One newsletter mentioning a topic once would carry the same weight as twenty engineers independently writing about it. The magazine would become a reflection of other magazines. Same reason I don't pull articles from other digest publishers: I'd just end up showing what they show, ordered the way they order it.

Community discussion is used for signal only. I do watch high-traffic places like the Kotlin Slack and a couple of subreddits — but only to detect what topics are trending, never as articles. A link someone pastes into Slack isn't an article: it's a mention, with no reliable publish date, often pointing at a homepage, a video, or a paper. Those feed the Topic Bible's sense of what's hot; they never appear as cards.

Open aggregator feeds (like Medium tags) are ingested, then filtered. They're noisy, so everything from them is vetted for real, on-topic, readable, this-week content before it can appear. Anything I can't actually open and date as a genuine article is dropped rather than published.

What I look for in a source

• Writes original content — analysis, tutorials, announcements, opinions, release notes
• Has an identifiable author or organization
• Publishes with datestamps I can parse — an article is dated by its own page, never by when it was mentioned
• Has been active within its own cadence recently

What disqualifies a source as an article feed

• Newsletters, roundups, and link aggregators — regardless of quality or reputation
• Sites that primarily re-publish or summarize content from elsewhere without original analysis
• Digest-format publications
• Sites without parseable publication dates — I can't verify freshness, so it can't be published

A few ways to help:

Add a source

Open sources/sources.yml and add an entry:

- id: your-source-id         # unique, kebab-case
  name: "Human-readable name"
  url: "https://example.com/"
  rss: "https://example.com/feed/"   # strongly preferred
  type: blog                 # blog | conference | changelog
  language: en
  cadence_days: 14
  topics: [kotlin, compose]

Open a PR. In the description, include one sentence on why this source adds something the existing list doesn't. If the source has an RSS or Atom feed, include it — the pipeline always prefers a feed over scraping.

Note: discussion feeds (e.g. Reddit) and slack-mirror channels are ingested for topic signal only — they shape what's trending but never render as articles, so they aren't held to the article bar above.

Report a dead source

If a source has gone quiet, open a PR removing it from sources/sources.yml. Include the last known article URL and date in the PR description so there's a record. The daily pipeline will eventually flag it automatically, but a human eye catches edge cases.

Add a topic

Open topics/topics.yml and add to the seed list or to the appropriate cluster. The pipeline auto-discovers new topics from article content, but curated seeds start with better placement:

- id: my-topic
  label: "Human Label"

Improve the site

The site is generated: assemble.py renders site/template.html (plus the current edition's data) into site/index.html. Edit template.html, not index.html — index.html is a build output and gets overwritten. Open a PR with before/after screenshots for visual changes.

Change the scoring constants

The Topic Bible's decay rate, source weights, and emergence threshold live in topics/topics.yml under scoring:. If you have data suggesting different constants would produce a better representation of community activity, open a PR with your reasoning.

State files committed to the repo: state/bible.json, state/source_health.json, state/articles.json. Full history is in git. You can look at any past commit and see exactly what the topic scores were on that day.

The site stores preferences in a browser cookie — no account, no server, no tracking.

{
  "topics": ["kotlin-core", "compose"],
  "keywords_include": ["gradle"],
  "keywords_exclude": ["flutter"],
  "language": "en"
}

FOCUS mode — select topics to see only those chapters. EXCLUDE mode — select topics to hide them; the rest of the magazine is unchanged. Losing the cookie resets to showing everything.

MIT. Take the pipeline, the site, the structure. Build your own digest for your own community. I only ask that you don't call it Kotlin Digest.

The best way to reach me is to open an issue on GitHub.