# wotaku's readme tells you not to open a pull request > Wotaku is a wiki-shaped index of sites with the most explicit submission policy on this site: a two-tier list of what will never be added and what will be avoided, three channels for submitting links, and a warning that direct contributions will be closed without a reason. Underneath it is a documentation site whose build asks Node for eight gigabytes of heap. **wotakumoe/wotaku** — An otaku index for everything! ⭐ Star the project if you like it! - Repository: https://github.com/wotakumoe/wotaku - Website: https://wotaku.wiki/ - Stars: 3,115 · Forks: 153 - Language: TypeScript - License: NOASSERTION - Published: 2026-09-24 · Updated: 2026-09-24 · Language: en - Canonical page: https://hysenlabs.com/projects/wotakumoe-wotaku ## An index whose most detailed documentation is its rejection list The project describes itself in six words as an otaku index for everything, and the rest of the page is about who is allowed to be in it. The submission section is a collapsed block headed with a warning symbol, and inside it are two lists with different force. The first is a refusal list with eight numbered categories. The second is a list of four things the maintainers will try to avoid, phrased as judgement rather than prohibition. That structure is the interesting part. A link directory with thousands of entries usually has no editorial policy at all, and the ones that do usually state it in a paragraph. Here the policy is the longest piece of prose on the page, split into a hard boundary and a soft one, with examples attached to most entries. The consequence for a submitter is that being turned down is the expected case rather than the exception, which is why the page spends its remaining length on where to submit and what happens if you submit the wrong way. The last section of the page is a star history embed, so even the closing note is about the project's visible popularity. ## Two of the refusal categories are about how a site gets its content The refusal list opens with categories a reader might expect from a curated index: sites that exist only or mainly for generative artificial intelligence, including chatbots, roleplaying bots and image generators, and a specific category of adult-content subscription platform. Then come the ones about provenance. A site is refused if it imitates another website, if it has very small libraries, if it only offers translated works, if it is mostly paywalled, if it sells unofficial merchandise, or if it exclusively sells one category of adult product. Two more categories are named by subject matter rather than by practice. The pair that matters most for an index are the last two of the practice rules: sites that scrape only a couple of popular sources, and sites that scrape the servers of other scrapers. The second is a rule about how a site obtains its data that names another aggregator as the source, which is a distinction most readers would not make and which the policy draws explicitly. The final entry defers to two community lists, linking an unsafe list on one wiki host and an untrusted-sites section of a page hosted on a forum. A site appearing on either is refused. So the policy has an external dependency: the definition of unacceptable partly lives outside the repository. The softer list adds closed source software where free alternatives exist, sites that only use named file hosting services, sites not primarily about anime with it as a side product, and anything too niche or too small to matter. ## Direct contributions will be closed without a reason The governance section is three channels and one prohibition, and the prohibition is the part that surprises people used to open-source documentation. A caution block states it plainly: do not open a pull request without going through the maintainers on their chat server first, because it will be closed without any reason given, and they may choose not to add a submitted site if they do not feel like it. So the repository is not the place to contribute to, even though that is where the content lives. The three accepted channels are the chat server, which the page labels as recommended; the site's own feedback button, which sits in the header of every section and needs no account; and a GitHub issue. That is a coherent arrangement for a project whose content is mostly links, because the hard part of adding an entry is the judgement rather than the edit. It also means the repository's apparent openness is misleading: the merge path anyone would reach for first is explicitly closed, and the page reserves the right to reject without explanation. The feedback button is the most interesting detail, because it removes the account requirement from the most likely path. A site whose content is a list of external links, and whose submission flow runs through a chat server, is optimising for conversation over throughput. ## Stars are the maintenance budget, and the page says so Two places on the page ask for the same thing. The repository description ends with an instruction to star the project if you like it. The opening line of the page says to consider giving the repository a star because stars motivate the maintainers to keep refining the wiki. And the page closes with a star history section, an embed that charts the count over time. Three mentions of the same request is a signal about the project's economics. A wiki of this size needs continuous maintenance, because links rot, hosts change and the categories of what belongs in the index shift with the ecosystem. The page's answer to that cost is visibility rather than funding, and it asks for the metric that costs a reader one click. That does not make the project fragile, but it does tell you where the risk sits. There is no statement about who maintains it, how many people review submissions, or what happens to the index if the maintainer loses interest. The only continuity signal on the page is the chat server. Set against the submission policy, it is a small team running a wide net, which is consistent with the refusal list being long and specific rather than short and general. ## The documentation build asks for eight gigabytes of heap The build script is the most technical line on the page, and it is a signal about scale. The docs build script sets Node's old-space size to eight gigabytes before running the documentation generator's build command. That override exists because the default heap is not enough, which means the set of pages and the amount of front matter being processed is large enough to matter. The rest of the scripts are the four you would expect for a documentation site: run a development server, build, preview a built site, and format the repository with a dedicated formatter that ships as a dependency rather than as a global tool. The documentation framework itself is pinned to a pre-release version of its 2.x line. Pinning a pre-release is a defensible choice when you need a feature the stable release does not have and you cannot wait, and it is also a maintenance obligation, because that pin has to be moved deliberately. Note what is not here. There is no test script, no lint script and no release process. The repository has no published releases at all, and the version in the manifest is the string zero. This is a site, not a package: it is built and deployed, and nobody installs it. ## A Markdown pipeline with a dozen plugins and a client-side search index The dependency list explains what kind of site this is, and it is a list-processing application rather than a content site. Most of it is Markdown. There are plugins for alignment, arbitrary attributes, figures, lazy image loading, image sizing, merged table cells, multiple-row tables, and regular-expression handling. That last one is the tell: a plugin that lets an author put a pattern in a document is a plugin for embedding search or highlight directives, which is what a link index with inline search would use. Then the client-side pieces: a search index library so queries run in the browser against the built pages rather than against a server, an image zoom plugin, and a schema validation library. Styling is a utility-first engine pinned to an exact version rather than a caret range, and there is an icon library plus a small set of community component packages. Two entries are odd together: the site's component tree is Vue, and a React version is also present in the dependency list, most likely pulled in by one of the plugins or component packages. The development dependencies are a set of icon collection packages, several of them for individual icon sets. That is what tells you the site resolves icons from a large collection registry at build time rather than shipping a fixed icon set. ## The repository is a documentation package, and its licence is asserted nowhere The manifest describes a package scoped to the project's own name, at version zero, with the module type set. It is not published anywhere and there is nothing to install, so the name and version exist to identify the workspace rather than to distribute it. The scripts confirm the shape: format, develop the docs, build them, preview them. Nothing else. The repository root is correspondingly thin. Beyond the documentation directory, the manifest, the workspace and lock files, and a TypeScript configuration, there is a formatter configuration, an editor configuration, a licence-header checker configuration, an SVG optimiser configuration, and a utility-first CSS configuration. That last pair of configurations is worth a second look. A link index accumulates a great many small graphics, and optimising them and styling them from utilities rather than from a stylesheet is a deliberate choice about how much hand-written presentation the site carries. On licensing, the repository has a licence file and a header-checking configuration that would enforce it across files, while the licence recorded against the repository itself is not asserted. For a project whose entire output is a list of other people's sites, that is a reasonable gap to close and an easy one. ## Conclusion Wotaku suits someone looking for a curated index rather than a search engine, and someone who is willing to read a policy before submitting anything. Three things to understand first. The policy is the product: two of the refused categories are about how a site gets its content rather than what it contains, so a link that looks harmless can still be rejected. Pull requests will be closed, so budget for a conversation instead. And the maintenance model is partly a request for stars, which tells you how thin the margin is on keeping the index current. ## FAQ ### What is Wotaku? It is an index presented as a wiki: a curated list of sites with an explicit submission policy, built as a documentation site whose content lives in the repository. The page asks readers to star the repository as the way to support continued refinement of the index. ### How do I submit a site to Wotaku? Three ways: the feedback button in the header of every section of the wiki, which needs no account, the project's chat server, which the page labels as recommended, or a GitHub issue. Opening a pull request directly is discouraged and will be closed without a reason given. ### What does Wotaku refuse to list? Sites that exist only or mainly for generative artificial intelligence, sites that imitate others, have very small libraries, only offer translated works, are mostly paywalled, sell unofficial merchandise or one category of adult product, a named category of adult-content subscription platform, overly general software, sites focused on two named subject categories, sites scraping only a couple of popular sources, sites scraping the servers of other scrapers, and sites listed in the unsafe lists of two community sites it links. ### What does Wotaku try to avoid listing? Four softer categories: closed source software where good free and open source alternatives exist, sites that only use named file hosting services, sites that are not primarily about anime but treat it as a side product, and anything too niche or with too small a userbase. ### Why does building the Wotaku documentation need a large memory limit? The build script sets Node's old-space size to eight gigabytes before running the documentation generator, which indicates the content set is large enough to exceed the default heap. The project has no releases and the manifest version is zero, so the site is built and deployed rather than published. ### What tools does the Wotaku repository use? A dedicated formatter shipped as a dependency, a licence-header checker configuration, an SVG optimiser configuration, a utility-first CSS engine pinned to an exact version, and a pnpm workspace. The documentation site itself adds about eight Markdown plugins, a client-side search library, an image zoom plugin and a set of icon collection packages in the development dependencies. ## Sources - [Issues](https://github.com/wotakumoe/wotaku/issues) - [Project website](https://wotaku.wiki/) - [README](https://github.com/wotakumoe/wotaku/blob/main/README.md) - [wotakumoe/wotaku on GitHub](https://github.com/wotakumoe/wotaku) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wotakumoe-wotaku