I Picked 5 Hacktoberfest Issues So You Don't Have To

This is a guide, not a challenge entry. See the note at the end before you submit anything.

There are about 139 open issues labelled hacktoberfest in tdk-landscape/tdk-cli-core. I counted them when I checked, so the number will have changed by the time you read this. Most are small. A good number are tagged for newcomers. Many look scary until you know how the labels work.

This post shows how to read the labels, what kinds of work are on offer, and five issues to start with.

How to read the labels

Every issue carries a few labels. Four matter most when you pick one:

• difficulty: easy means a few hours, little repo knowledge needed. difficulty: medium means a day or two and some repo knowledge.
• area: … tells you which part of the repo you will touch: area: cli (the tdk CLI in cli/), area: engine, area: tests, area: documentation, area: tui, and a few others.
• rank: N kyu is a rough scale from 8 kyu (documentation, small fix) to 6 kyu (a refactor that needs context). The lower the number, the harder the task.
• island: … groups issues by theme, such as Docs Harbor, Test Atoll, Engine Volcano, and CLI Cove. If you like one island, you can work through its issues in order.

Roughly sorted, the open Hacktoberfest issues break down like this:

Area	About how many	What the work looks like
Documentation	~44	Translations and doc fixes, mostly difficulty: easy
CLI	~16	Small fixes, validation, and error-message consistency
Tests	~4	Adding tests for code that already works
TUI	~9	Dashboard (tdk ui) improvements
Engine	~5	Refactors of the Compose and Starlark generation

These counts come from the labels. An issue can have more than one area, so the rows do not add up exactly to 139.

Where to start: the easy wins

If you have never contributed to TDK, start with a translation or a documentation issue. They are difficulty: easy, they need no code, and they are a good way to learn the contribution flow. The docs come in several languages, and each language has its own issue. Pick one language you read well.

Examples from the open list:

• #1131: map the Starlark topology module boundaries (difficulty: easy, rank: 8 kyu). Update engine/topologies/README.md with a current map of the Starlark topology modules and how a service.json reaches the generated Compose and Tilt files. This one asks you to read code and write it up.
• #1130: cover generated Docker network initialization and cleanup commands (difficulty: easy, rank: 7 kyu, area: tests). Add tests for code paths that already exist. Tests are a good first contribution because you learn the codebase without changing its behaviour.
• #1126: parse Compose load-balancer ports in one helper (difficulty: easy, rank: 7 kyu, area: engine). A small refactor that puts repeated port parsing into one helper. Good if you want to touch the engine without a big change.
• #1177: add tests for the Compose helper paths in Starlark (difficulty: easy, rank: 7 kyu, area: tests). Another test task, with a Portuguese title. The issue text is in the language of the translation.
• #1174: test the generated Axum routes over HTTP (difficulty: medium, rank: 6 kyu). A step up: you run a generated Rust service and check its routes. Take this after one easy test issue.

The easy documentation issues are also a good first pick. Translations such as [Deutsch] Ins Deutsche übersetzen: Smoke-Test or [简体中文] ui 翻译为简体中文 each map to one doc page.

Before you open a pull request

The repo has a few rules that the automated checks enforce:

1. Sign off every commit. Each commit needs a Developer Certificate of Origin line. Use git commit -s, which adds Signed-off-by: Your Name <[e-mail]>. The pull request check fails if a commit is missing it. If you forgot, run git rebase --signoff origin/main and force-push your branch.
2. Keep the change small. One issue, one pull request. The difficulty: easy issues are built for a single focused change.
3. Read CONTRIBUTING.md first. It describes the labels above and the rest of the process.
4. Lint by exit code. Run the same lint command the CI runs and read its exit status. A tail on the output can hide a failure.

Why this is a good first project

TDK CLI is a local tool that runs a whole stack with Docker and Tilt. Contributing to it teaches you more than one thing at a time: how a CLI is structured, how generated Docker and Compose files are produced, and how tests check them. An easy issue takes an afternoon, and the reviews are usually quick.

If you want more background first, the TDK CLI README explains what the tool does, and the example repos show it running a real stack.

A note on DEV challenges

I checked the DEV Hacktoberfest challenge pages before writing this. The current challenge (Week 2, "Side Hustle") has one prompt for all five weeks: "Build something with open-source AI at its core." Its rules say a submission must be a new project built during that challenge's window, and that pull requests to existing projects don't count. Week 2 closes on October 18, 2026.

This post is a guide to contributing, so it does not meet those rules as a challenge entry. If you want to enter a challenge with TDK, build a new project that uses TDK and an open-source model, and write about that.

Written as a guide to the open Hacktoberfest issues in TDK CLI, checked on October 18, 2026.