Este wiki es el hogar de investigación de la comunidad, y hay sitio en él para tu trabajo. Tres formas de publicarlo, desde un mensaje en la lista de correo hasta una pull request, más el pequeño conjunto de reglas de la casa que mantiene cada página digna de confianza.
Este wiki no es el blog de una sola persona con la puerta cerrada. Pretende ser el hogar de investigación de la comunidad: el lugar donde diecinueve años de trabajo sobre Eternity II (récords, métodos, hallazgos estructurales, callejones sin salida incluidos) quedan consignados, referenciados y a mano para encontrarlos. Cada página del laboratorio lleva la firma de su autor y se reúne en la página de contribuidor de ese investigador, hoy sobre todo la de Raphaël, porque es quien se toma la molestia de escribirlo todo, pero la estructura acredita a cada contribuidor por su nombre. La tuya puede situarse justo al lado de la suya.
Empieza construyendo. La caja de herramientas del constructor te lleva a un solucionador que se ejecuta, y para un primer objetivo con el que hacerte un nombre, el 10×10 set_2 de Brendan Owen es el tablero sin resolver más cercano por debajo del puzzle completo. Un resultado ahí merece traerse de vuelta aquí.
Ya existe un precedente. La página sobre el algoritmo de Blackwood se apoya en las notas y el estudio de parámetros de Jef Bucas, republicados con su permiso explícito, sus figuras y su nombre en cada una de ellas. Ese es el modelo: el trabajo sigue siendo tuyo, el wiki le da un hogar permanente y citable.
1. Publícalo y señálalo: la vía más ligera. Comparte tu hallazgo allí donde la comunidad ya conversa: la lista de correo o el servidor de Discord. Si quieres verlo en el wiki, basta con decirlo en tu mensaje. Alguien (normalmente Raphaël) lo redactará como página, te la someterá a revisión y la publicará con todo el crédito. Así es exactamente como nació la página de Blackwood a partir de las notas de Jef. Nunca tienes que tocar el repositorio.
2. Abre una issue o una pull request. El wiki es
un repositorio abierto, y una
página de investigación no es más que un archivo MDX bajo
web/content/research/. Añadir el archivo es el registro: la barra lateral,
la búsqueda y el sitemap lo recogen automáticamente. Cada página empieza con un
pequeño bloque 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 página es un experimento (una búsqueda que has medido), se requiere un bloque más: el hardware sobre el que se ejecutó. Es lo que permite a un lector comparar tu resultado con el de todos los demás, y el build rechaza una página de experimento que carezca de él.
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 página lo representa como una ficha técnica con una sola cifra-titular
derivada: los núcleos-hora (núcleos × horas de tiempo real), el coste
verdadero de la ejecución. Esa única cifra es lo que sitúa una búsqueda de un
núcleo y un minuto y un barrido de 400 núcleos en un centro de datos en la misma
tabla sin que uno favorezca al otro. Pon measured: true solo para una
referencia mononúcleo estandarizada (un núcleo, un presupuesto de tiempo fijo);
una ejecución multinúcleo es un native run y consigna su equipo real y la
mejor puntuación que alcanzó.
¿No lo tienes claro con la fontanería? Abre una issue con tu borrador en markdown simple y nosotros nos ocupamos del resto. Ejecútalo tú mismo explica cómo poner el sitio en marcha en local si quieres previsualizar tu página.
3. Comparte datos y tableros. No todo necesita prosa. Un buen tablero, un barrido de parámetros, un conjunto de datos de una ejecución larga: todo ello es bienvenido. Cada tablero de este sitio es verificable en el visualizador, que habla de forma nativa el formato de URL estándar de la comunidad, de modo que cualquiera puede comprobar tu resultado con un clic. Publica el tablero o los datos con una nota sobre cómo se produjeron, y puede respaldar una página o convertirse en una.
Existen por una sola razón: para que cualquiera que llegue a cualquier página pueda confiar en lo que lee.
report para un informe técnico público pero aún sin revisar,
y live para una página revisada, citada y tratada como asentada (draft es el
estado sin publicar que rara vez se ve).hardware: de arriba (núcleos, equipo, presupuesto de tiempo). El build
lo exige. Una puntuación sin cómputo detrás no es un resultado que nadie pueda
comparar.A cambio de cumplir esas reglas, tu trabajo recibe una infraestructura que un
mensaje de foro nunca tendrá: una página estable en el armazón de la
documentación con barra lateral, búsqueda y migas de pan; una ubicación en los
centros temáticos para que se encuentre por tema, y no solo por
fecha; una exportación en markdown en bruto de cada página (añade .md a su URL)
para que siga siendo legible por máquina; y una URL permanente que otros
investigadores podrán citar, dentro de años y no solo esta semana.
El puzzle ha resistido a todo el mundo hasta ahora. Lo mínimo que podemos hacer es asegurarnos de que el progreso de nadie contra él se pierda.