Le pagine nascono dal lavoro sul network
EclipsMC non separa completamente sviluppo e documentazione. Quando una modifica richiede di capire perché una cage non viene generata, perché due scoreboard mostrano dati differenti o perché una pagina funziona su desktop ma non su telefono, il risultato del test diventa anche materiale per migliorare guide e procedure interne.
Questo approccio ci permette di pubblicare contenuti che descrivono decisioni realmente affrontate, invece di riscrivere soltanto concetti generici su Minecraft. Le informazioni stabili entrano nel Codex o nelle Guide; i casi tecnici più utili vengono raccolti in Eclips Lab con contesto, controlli eseguiti e criterio usato per considerare il problema risolto.
Preferiamo una funzione verificata a tre funzioni “quasi pronte”
Una modifica viene provata nel flusso completo: ingresso, azione, uscita, permessi, messaggi e persistenza dopo riavvio quando il dato deve essere salvato. Per le pagine web controlliamo anche mobile e stati senza autenticazione; per le modalità di gioco verifichiamo ciò che il giocatore vede in lobby, in partita e al ritorno.
La roadmap distingue idee, pianificazione, sviluppo, testing e completamento proprio per evitare che una funzione ancora instabile venga presentata come disponibile.
Correzioni, changelog e casi di studio hanno ruoli diversi
Il Codex risponde a “come è organizzato e cosa significa”. Il changelog risponde a “cosa è cambiato”. La roadmap risponde a “a che punto siamo”. Eclips Lab risponde a “perché abbiamo fatto questa scelta e cosa abbiamo imparato”. Separare questi livelli rende le informazioni più facili da trovare e riduce il rischio di usare annunci brevi come sostituto della documentazione.
Quando una pagina contiene informazioni che possono cambiare, indichiamo una data di aggiornamento e colleghiamo il lettore alle pagine correlate. Se una funzione è ancora in test, deve essere descritta come tale.