Ce wiki est le foyer de recherche de la communauté, et il y a de la place pour votre travail. Trois façons de le faire publier, du message sur la liste de diffusion à la pull request, plus le petit jeu de règles maison qui garde chaque page digne de confiance.
Ce wiki n'est pas le blog d'une seule personne, porte close. Il se veut le foyer de recherche de la communauté : l'endroit où dix-neuf ans de travail sur Eternity II (records, méthodes, résultats structurels, impasses comprises) sont consignés, sourcés et gardés trouvables. Chaque page du labo porte la signature de son auteur et se rassemble sur la page contributeur de ce chercheur, aujourd'hui surtout celle de Raphaël, parce que c'est lui qui prend la peine de tout écrire, mais la structure crédite chaque contributeur par son nom. La vôtre peut prendre place juste à côté de la sienne.
Commencez par construire. La boîte à outils du bâtisseur vous mène à un solveur qui tourne, et pour une première cible où vous faire un nom, le 10×10 set_2 de Brendan Owen est le plateau non résolu le plus proche sous le puzzle complet. Un résultat là-dessus mérite d'être rapporté ici.
Il existe déjà un précédent. La page sur l'algorithme de Blackwood repose sur les notes et l'étude de paramètres de Jef Bucas, republiées avec son accord explicite, ses figures et son nom sur chacune d'elles. C'est le modèle : le travail reste le vôtre, le wiki lui offre un foyer permanent et citable.
1. Postez-le et signalez-le : la voie la plus légère. Partagez votre découverte là où la communauté discute déjà : la liste de diffusion ou le serveur Discord. Si vous souhaitez la voir sur le wiki, dites-le simplement dans votre message. Quelqu'un (généralement Raphaël) en rédigera une page, vous la soumettra, et la publiera avec tout le crédit qui vous revient. C'est exactement ainsi que la page Blackwood est née des notes de Jef. Vous n'avez jamais à toucher au dépôt.
2. Ouvrez une issue ou une pull request. Le wiki est
un dépôt ouvert, et une page de
recherche n'est rien de plus qu'un fichier MDX sous
web/content/research/. Ajouter le fichier est l'enregistrement : la barre
latérale, la recherche et le sitemap le prennent en compte automatiquement.
Chaque page commence par un petit bloc de frontmatter :
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/10754Si la page est une expérience (une recherche que vous avez mesurée), un bloc supplémentaire est requis : le matériel sur lequel elle a tourné. C'est ce qui permet à un lecteur de comparer votre résultat à celui de tous les autres, et le build refuse une page d'expérience qui en est dépourvue.
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 benchLa page en fait une fiche technique avec un seul chiffre-titre dérivé : les
cœurs-heures (cœurs × heures de temps réel), le coût véritable de la
recherche. C'est ce chiffre unique qui met une recherche à un cœur et une minute
et un balayage sur 400 cœurs en centre de données dans la même table sans que
l'un flatte l'autre. Ne mettez measured: true que pour une référence
mono-cœur standardisée (un cœur, un budget de temps fixe) ; une recherche
multi-cœurs est un native run et consigne son matériel réel ainsi que le
meilleur score atteint.
Pas sûr de la tuyauterie ? Ouvrez une issue avec votre brouillon en markdown simple et nous nous occupons du reste. Faites-le tourner vous-même explique comment lancer le site en local si vous voulez prévisualiser votre page.
3. Partagez données et plateaux. Tout n'a pas besoin de prose. Un bon plateau, un balayage de paramètres, un jeu de données issu d'une longue recherche : tout cela est le bienvenu. Chaque plateau de ce site est vérifiable dans le visualiseur, qui parle nativement le format d'URL standard de la communauté, si bien que n'importe qui peut contrôler votre résultat en un clic. Postez le plateau ou les données avec une note sur leur production, et cela peut étayer une page ou en devenir une.
Elles existent pour une seule raison : que quiconque tombe sur n'importe quelle page puisse faire confiance à ce qu'il lit.
report pour un
compte rendu technique public mais pas encore relu, et live pour une page
relue, citée et considérée comme acquise (draft étant l'état non publié que
l'on croise rarement).hardware: ci-dessus (cœurs, matériel, budget de temps). Le build l'impose.
Un score sans calcul derrière lui n'est pas un résultat que l'on peut
comparer.En échange du respect de ces règles, votre travail reçoit une infrastructure
qu'un message de forum n'aura jamais : une page stable dans l'habillage de la
documentation avec barre latérale, recherche et fil d'Ariane ; un rangement dans
les pôles thématiques pour qu'on la trouve par thème, et pas
seulement par date ; un export en markdown brut de chaque page (ajoutez .md à
son URL) pour qu'elle reste lisible par machine ; et une URL permanente que
d'autres chercheurs pourront citer, des années plus tard et pas seulement cette
semaine.
Le puzzle a résisté à tout le monde jusqu'ici. Le moins que l'on puisse faire, c'est de veiller à ce que les progrès de personne contre lui ne se perdent.