dooit: the star and issue badges point at a repository one letter shorter

The star link, the issue link and the manifest all name a different repository

Start with the links, because they are the part a visitor touches first. The star badge and the issue badge in the readme both point at an organisation path whose project name has one fewer letter than this repository's. The packaging metadata repeats the same name in two places, its homepage field and its repository field. Everything else on the page is correct: the documentation site, the Discord invite, the changelog link, the wiki link. So the failure is narrow and it lands on the two buttons that matter most. Counting the stars lands on someone else's counter, and clicking through to report a bug lands on a different tracker. That matters more here than it would elsewhere, because the contribution section explicitly asks people to open pull requests and to open issues, and because customisation requests are rerouted to yet another repository. A project with three places to report things cannot afford the one advertised place to be wrong, and a one-character fix is all it takes.

There is no install command on the page, and three plausible install paths

For installation and configuration, the page sends you to the wiki, which is hosted as a documentation site rather than living in the repository. So there is nothing to copy from the front page. What the repository itself tells you is thin but real: the packaging declares a console entry point bound to the package's main module, and the language floor is one version line. The dependency list is short for an application with a database behind it: a command line parser, a directory-locating library, a clipboard library, a YAML parser, two date and time zone libraries, the terminal UI framework and the mapper. Then there is the packaging tree. A Nix flake with its own lock file and a directory of Nix definitions sit beside a lock file for a fast Python package manager, so there are at least three ways to get this running and none of them is described here. For a tool whose pitch is that you press a key and start working, that is an unusual amount of setup to hide behind a wiki.

Three screenshot blocks, all of them empty

The screenshots section is three collapsible blocks, each labelled with a colour scheme: one described as icy, one as colourful and one as calm, named after three popular terminal themes. Every one of them is empty in the source, so a reader who clicks all three gets three headings and no pictures. The images are not missing from the project. There is an image directory in the tree, and the packaging configuration explicitly excludes that directory from the distributed package, which means the pictures live in the repository and are simply not embedded in the page. For a project whose first listed feature is its appearance, and whose readme jokes that you did not ask for it but needed it, the one page element that would demonstrate the claim is blank in all three places. The rest of the section is honest about its own limits: a note says the configurations shown heavily use a separate add-on repository, which is the same repository customisation requests are routed to.

A terminal UI framework and an object-relational mapper, and nothing says where the data lives

The dependency list explains the architecture better than the feature list does. The interface comes from a terminal user-interface framework at version six or later, which explains two things elsewhere in the packaging: the test suite runs in asynchronous mode by default rather than per test, and a development tool for that same framework sits in the development group. Storage goes through an object-relational mapper at version two, so this is not a text file of lines with checkboxes, and it means there is a schema somewhere. Around those sit a library for locating per-user directories, which is where a configuration file and any data will live, a clipboard library, a YAML parser for the configuration, two date and time zone libraries, and the command line parser that provides the entry point. Here is the part that is missing: no line of the page, and no line of the manifest, says where your todos are stored, whether you can sync them, or how to back them up. For a todo manager that is the first question after installation.

Configuration is a Python file you execute, and it is the one file excluded from coverage

Extensibility is described in one line: a Python configuration file that lets you do as much as you like. That is a bigger commitment than a settings file, because the configuration is code in your own interpreter, and it makes the project extensible in a way a data file never could. The readme also draws a line between the two projects in the family. If your idea relates to customisability, you are asked to open an issue against a separate add-on repository instead, and the screenshot configurations are said to rely on it heavily. So theming has its own repository, its own issue tracker and its own release cycle, and the boundary is maintained socially. Then there is the coverage configuration, which omits the Nix store paths and exactly one source file: the default configuration. The file every user starts from, and the file whose contents the application copies into your own directory, is the one file the project does not measure.

A build backend, a fast dependency manager and a Nix environment, for eight dependencies

Read the tooling sections together and the project's priorities come through clearly. The build uses a current build backend. The lock file belongs to a fast Python package manager rather than to the older tooling, and the development environment is described by a Nix flake with a pinned revision and a directory of Nix definitions. Three toolchains layered onto an application with eight runtime dependencies is more machinery than the project strictly needs, and far more than anyone installing from a wheel will ever touch. The test side is just as deliberate. The linter has exactly one rule switched off, which is the comparison against boolean literals. The async test mode is set once for the whole suite. The development group carries a fake data generator, so tests are built on generated records rather than fixtures someone maintained. Coverage is pointed at the test directory, and the two omissions above are the only two. This is a project whose maintainer spends attention on the toolchain, and it is worth knowing that before you file a bug about a missing test.

One sibling project is listed in the plural, and the changelog is the real documentation

The closing sections are short. The readme points at the changelog for details on changes and additions, which is the correct instruction for a project that shipped three releases in the second half of 2025 and continues to add features. At the bottom it invites you to try other terminal projects by the same author, in the plural, and lists one: a typing test application for the terminal. The usage section is one sentence long, and it says that after launching the application you can press the question mark key to find out the keybindings, which tells you how self-describing the interface is meant to be. Underneath the title, the tagline describes the project as something you did not ask for but needed, which is a fair description of a tool that replaces whatever system you were using. So the front page is short by design; it is just also wrong in two places, and the changelog is where the actual project lives.

Editorial conclusion

Use dooit if you live in a terminal and want a todo list with vim-style keys, colour schemes you can switch and lists that branch, and be willing to read a wiki rather than a manual. Three things to check before you rely on it. Where your data actually lives, because the dependency list shows an object-relational mapper behind the interface and the page never says how to back it up or move it. Where configuration lives, because it is a Python file you execute and the coverage report deliberately excludes the default version of it from testing. And where bugs go, because the issue link on the front page points at a differently named repository while the project's contribution section asks you to open a pull request here. Nothing about the project is fragile; it is the front page that needs a pass.

Frequently asked questions

Official sources

1. dooit-org/dooit on GitHub
2. License: MIT
3. Project website
4. README
5. Releases