This wiki is the community's research home, and there is room in it for your work. Three ways to get it published, from a mailing-list post to a pull request, plus the small set of house rules that keep every page trustworthy.
This wiki is not one person's blog with the door closed. It is meant to be the community's research home: the place where nineteen years of Eternity II work (records, methods, structural findings, dead ends included) gets written down, sourced, and kept findable. Every page in the lab carries an author byline and gathers on that researcher's contributor page, today mostly Raphaël's, because he is the one writing things down, but the structure credits each contributor by name. Yours can sit right beside his.
Start by building. The builder's toolkit gets you to a running solver, and for a first target with a name to make, Brendan Owen's 10×10 set_2 is the nearest unsolved board below the full puzzle. A result there is worth bringing back here.
There is already a precedent. The page on Blackwood's algorithm is built on Jef Bucas's notes and parameter study, republished with his explicit permission, his figures, and his name on every one of them. That is the model: the work stays yours, the wiki gives it a permanent, citable home.
1. Post it and flag it: the lightest path. Share your finding where the community already talks: the mailing list or the Discord server. If you would like it on the wiki, just say so in the post. Someone (usually Raphaël) will write it up as a page, run it past you, and publish it with full credit. That is exactly how the Blackwood page came to exist from Jef's notes. You never have to touch the repository.
2. Open an issue or a pull request. The wiki is
an open repository, and a
research page is nothing more than one MDX file under
web/content/research/. Adding the file is the registration: the sidebar,
search, and sitemap pick it up automatically. Each page starts with a small
frontmatter block:
title: Your finding, in one line
description: >-
Two or three sentences that can stand alone in a search result.
kind: finding # or experiment, concept, reference...
updated: 2026-07-02
topics: [backtracking]
sources:
- label: Hopfer's statement of the NS-1 condition (2022)
url: https://groups.io/g/eternity2/message/10754If the page is an experiment (a search run you measured), one more block is required: the hardware it ran on. It is what lets a reader compare your result to everyone else's, and the build refuses an experiment page without it.
kind: experiment
hardware:
cores: 1 # logical cores used; sum across nodes for a cluster
cpu: "AMD Ryzen 9 7950X"
ramGb: 64
gpus: 0
accelerator: none # none | gpu | quantum | fpga | tpu
machine: "desktop, single box"
wallClock: "10 × 60 s" # budget per run × repeats
runs: 10
seedPolicy: "randomized corner permutation per run"
measured: true # true only for the standardized single-core benchThe page renders this as a spec card with one derived headline: core-hours
(cores × wall-clock hours), the true cost of the run. That single number is
what puts a one-core, one-minute search and a 400-core datacenter sweep in the
same table without one flattering the other. Set measured: true only for a
standardized single-core baseline (one core, a fixed time budget); a many-core
run is a native run and records its real kit and the best score it reached.
Not sure about the plumbing? Open an issue with your draft in plain markdown and we will handle the rest. Run it yourself covers getting the site running locally if you want to preview your page.
3. Share data and boards. Not everything needs prose. A strong board, a parameter sweep, a dataset from a long run: all of it is welcome. Every board on this site is verifiable in the viewer, which speaks the community's standard URL format natively, so anyone can check your result in one click. Post the board or the data with a note on how it was produced, and it can back a page or become one.
They exist for one reason: so that anyone landing on any page can trust what they read.
report
for a technical write-up that is public but not yet reviewed, and live for a
reviewed page that is cited and treated as settled (draft is the unpublished
state you rarely see).hardware: block
above (cores, kit, time budget). The build enforces it. A score with no
compute behind it is not a result anyone can compare.In exchange for meeting those rules, your work gets infrastructure that a
forum post never has: a stable page in the docs shell with sidebar, search and
breadcrumbs; placement in the topic hubs so it is found by
theme, not just by date; a raw-markdown export of every page (append .md to
its URL) so it stays machine-readable; and a permanent URL other researchers
can cite, years from now and not just this week.
The puzzle has resisted everyone so far. The least we can do is make sure nobody's progress against it gets lost.