Il manutentore ha risposto — e mi ha corretto, a ragione

Nella prima parte ho valutato male un progetto. Nella seconda ho trovato e segnalato due errori bloccanti.

In questa il manutentore risponde — e smonta una delle mie misure. A ragione.

La riga di credito è arrivata da sola

Prima la parte piacevole. Nella notte è comparsa una nuova versione preliminare e una lunga risposta alle mie due segnalazioni. Dentro, senza che l’avessi chiesto:

«the [0.3.0] credit line — that is yours, and it should have been there when it shipped.»

Senza che nessuno dovesse chiederlo. La piccola irritazione per il mio contributo non citato nelle note di versione si era risolta prima ancora di essere espressa.

È una forma di collaborazione che si racconta di rado perché non è spettacolare: qualcuno si accorge da solo che manca un riconoscimento e lo corregge.

E poi la frase che ha colpito

Nella mia segnalazione c’era una tabella. Dentro, una riga come controprova: un modello di telecamera a cui una certa funzione viene correttamente rifiutata, contrapposto a un altro a cui viene erroneamente concessa.

La risposta:

«that row measured our config, not the camera»

Ha ragione. Il codice di errore nella mia riga era reale. La parola «correttamente» no.

La funzione funziona su quel modello. Semplicemente, la configurazione distribuita del progetto lo teneva in una lista di esclusione. La mia misura ha quindi misurato che quella lista fa effetto — non che la telecamera non ne sia capace.

Perché non me ne sono accorto

È questa la parte davvero istruttiva. Una controprova confermata stava da settimane nella stessa cartella che avevo scaricato e perquisito.

Non ho guardato perché la lista di esclusione sembrava un’impostazione intenzionale — e ciò che sembra intenzionale non lo si mette in discussione.

Un’impostazione predefinita sembra conoscenza. È solo l’ipotesi di qualcun altro, nel momento in cui l’ha scritta.

Entrambe le liste ora vengono distribuite vuote, e il commento lì dice cosa ci vada dentro: una famiglia di apparecchi che tecnicamente non può — una proprietà del trasporto, non del modello.

E un limite del metodo che avrei dovuto dichiarare

La mia prova era una stretta di mano contro un’interfaccia: si apre o rifiuta?

Questo mostra se il varco si apre. Non può mai mostrare se la telecamera dietro sia capace, perché in quella prova alla telecamera non arriva proprio nulla.

Per il mio ritrovamento vero era esattamente lo strumento giusto. Per la riga accanto era quello sbagliato — e ho dato a entrambe lo stesso peso.

Terzo errore dello stesso tipo in un giorno

La parte scomoda non è il singolo errore ma lo schema. Lo stesso giorno me ne erano capitati altri due della stessa specie:

• un numero scambiato con un altro perché entrambi sembravano plausibili
• una misura presa troppo presto dopo un riavvio e scambiata per lo stato normale
• e ora: un’impostazione predefinita scambiata per una misura

Lo schema è sempre lo stesso: vedere un numero, inventare l’interpretazione, e non porre la domanda di controllo ovvia.

La domanda di controllo sarebbe stata diversa ogni volta, ma ce ne sarebbe sempre stata una. Per la lista di esclusione: esiste da qualche parte una misura che mostra il contrario? Stava due cartelle più in là.

E ha smentito anche il mio secondo sospetto

Avevo segnalato che una certa famiglia di telecamere era peggiorata in una versione più recente — una regressione, quindi.

La controprova da lì era migliore della mia:

• Il file in questione è identico byte per byte attraverso cinque versioni. Nessun commit l’ha toccato.
• I campi che trovavo sospetti il programma non li legge affatto. Prende esattamente un valore e con quello apre il flusso.

La mia «regressione» non esisteva. Avevo visto due cose accanto — una nuova versione e un comportamento peggiore — e ne avevo fatto una causa.

Lo stesso schema delle telecamere stesse, dove ho formulato sette spiegazioni e tutte e sette sono cadute. E lo stesso delle misure di rete, dove l’attribuzione dipendeva da due ore di fuso orario.

Cosa mi sono portato via

1. Distingui ciò che il tuo strumento può misurare da ciò che vuoi sapere. Una stretta di mano verifica un varco, non una telecamera. Vale per ogni prova indiretta.
2. Un’impostazione predefinita non è una misura. È l’ipotesi di qualcuno, in un momento che non conosci.
3. Cerca attivamente la controprova prima di segnalare. La mia era nella stessa cartella. Sarebbe bastato un grep.
4. Dai pesi diversi ai tuoi riscontri. Ho scritto un ritrovamento ben documentato e una nota marginale poco documentata con la stessa sicurezza. Questo rende attaccabile il ritrovamento buono.
5. Accetta le correzioni in pubblico. Chi segnala un errore deve saper reggere che gliene venga segnalato uno — altrimenti smettono entrambe le cose.

E quindi?

Tre parti su un progetto che avevo dato per mezzo morto. Alla fine ci sono: una licenza MIT, un accesso che funziona, un’immagine dal vivo nella mia dashboard, e un progetto che ora sta nel catalogo predefinito delle estensioni di Home Assistant.

Il mio contributo è stato piccolo ed è consistito quasi solo nel descrivere con precisione. Nessuna funzione, nessuna architettura: due segnalazioni con estratto di registro e punto nel sorgente.

Quello che ho imparato riguarda più me che le telecamere: tendo a dedurre uno stato da un’istantanea. Con la valutazione del progetto, con la lista di esclusione, con la presunta regressione — tre volte la stessa cosa.

Che ogni volta sia emerso non dipende da me. Dipende dal fatto che qualcun altro ha guardato.