Roadmap: what's open, how hard it is, and how to claim it

[LeyckerS]

This is the landing page for anyone who wants to contribute. Everything open is listed below, ranked by size, with the two things that actually matter up front: how hard it is, and whether you need Windows.

MoonDownloader runs on Windows, but almost none of the open work requires it. Documentation, CI, tests and dependency work all run on Linux and macOS, and the test suite stubs Chrome and the network at the moon_extract boundary so it runs anywhere. Exactly one open issue needs a Windows machine, and it says so.

Most of the bugs below were found by using the program, not by reading it. Several come with measurements from real runs in the issue itself, so you can check the fix against a number instead of a feeling.

Last checked against the repository: 6 August 2026.

Never contributed to open source before?

Three issues are reserved for people who have never had a pull request merged anywhere. All three are done entirely in the browser — no install, no command line, nothing to run.

Issue	What you change
#79	One line of a comment in ruff.toml that describes its own effect incorrectly
#80	Delete one unused constant from moon_engine.py
#93	One line so a CI workflow watches its own file on pull requests, as it already does on push

The work is deliberately small. The point is to get you through fork → edit → pull request once, with every step written out. If you get stuck halfway, say so on the issue — that is what it is there for.

If you have contributed before, please leave these three and take something below.

Free right now

Nothing here is claimed. No Windows machine needed unless the row says so.

Issue	What it is	Size	Needs Windows
#85	The ETA clamps to exactly 2 hours and presents it as a real number. Plus a skewed average early on and visible jitter from a 3-second window	~25 lines	No
#83	Extractors sits under "COMMON — BOTH METHODS" but datanodes is hard-capped at 8 lanes. Measured: fuckingfast keeps ~40 of 48 download slots busy, datanodes keeps ~4	~20 lines	Helpful
#32	moon_cli.py exits non-zero on a missing URL file and on a crash, but a run that completes always exits 0 — whether one file failed or all of them did. Ctrl-C also exits 0. A script cannot tell success from total failure	~20 lines	No
#151	aiohttp.BasicAuth is deprecated and goes away in 4.0. One call site — but the fix the warning suggests is the wrong header for a proxy, and the replacement function does not exist at the declared version floor	Small; the reading is the work	No
#97	moon_cli.py keeps its own progress accounting instead of using Engine.snapshot() — including a character-for-character copy of the speed expression from #84	Larger	No
#64	A square backdrop appears behind the progress rings during a run	GUI/CSS	Yes

#85 is the most valuable one free. It is on screen for the whole run, and the fix is arithmetic plus a decision about what to show when the estimate is not yet meaningful — no engine internals required.

Claimed, in progress

Listed so nobody duplicates the work. If one has gone quiet for five days it goes back to the free table above, and returning is always welcome.

Issue	Who	State
#116	@shard872	PR #150 open — disk-full detection, approved, rebasing onto #149
#117	@tomatotomata	The COMPLETED counter reporting failures as completions
#84	@happykawayigt	MiB/MB unit mismatch, all labelled "MB/s"
#81	@nightcityblade	ruff running three times per pull request
#145	@AashishGupta2007	The unreferenced THEME colour block — why it is there, not just that it is dead
#57	@Abel-et	Unit tests for Engine.snapshot()

Recently shipped

Some context on what the work here looks like when it lands:

• bug: Stop leaves the UI on STOPPING until every in-flight download finishes on its own #65 — Stop now interrupts transfers already in flight (@Allen58562, Stop in-flight downloads when stopping engine #149). The engine keeps each active download's kill event in a registry and signals it with loop.call_soon_threadsafe; a user stop is recorded as stopped so the retry path cannot re-queue it and undo the stop.
• fix: update proxy status handling (#115) #132 — the proxy chip tells the truth before a run starts (@8nt0n), distinguishing "no file" from "file with nothing usable in it".
• engine/cli: collect and report browser worker failures #143 — both worker gathers collect their failures (@PomPomSaturin) instead of aborting on the first one, and name the worker that failed.
• V4 repaired both providers after they changed how they hand out links.

How to claim one

Comment on the issue saying you are taking it. You will be assigned, usually within a few hours. You do not need to ask permission first, and you do not need to have a plan — saying "taking this, not sure yet how" is fine and gets you the same answer.

A claim holds for five days. After that the issue goes back to the free table so it is not parked indefinitely — no blame attached, and you are welcome to pick it up again.

Two things worth knowing before you start:

1. Read the function, not the description. Issue bodies here are written by the maintainer and have been wrong before — docs(cli): fix stale --proxies row and document the actual warning behavior #63 was merged partly because it corrected a mistake in the issue that opened it. If the code disagrees with the issue, the code wins and I would rather hear it.
2. Keep the diff to the issue. Reformatting, renaming and "while I was in there" edits are the most common reason a pull request needs a second round, even when each change is harmless on its own.

CONTRIBUTING.md has the verification commands. Everything else — architecture, style, the rules that are not preferences — is in there too, and nothing in this issue repeats it.