Languages: English • Italiano • (Add your language)

Questa pagina ha lo scopo di aiutare a spiegare la strategia di rilascio utilizzata dagli sviluppatori di WordPress.

Il team è acutamente consapevole dell'importanza ricoperta dal rilascio di aggiornamenti senza errori e dolori per gli utenti con ogni livello di abilità. Mantenere questa tradizione è di primaria importanza.

Lettura suggerita di Ryan Boren sull'importanza di mantenere il numero di opzioni e preferenze al minimo indispensabile (e sulla creazione di software libero in generale):

http://ometer.com/free-software-ui.html

È un dato di fatto che le preferenze hanno un costo. Certamente alcune preferenze hanno anche benefici importanti - e possono essere caratteristiche cruciali dell'interfaccia. Ma ognuna di esse ha un prezzo, e bisogna considerare attentamente il suo valore. Molti utenti e sviluppatori non capiscono questo e finiscono con l'avere preferenze dall'alto costo e dal basso valore.

• Troppe preferenze portano a non riuscire a trovarne nessuna.
• Le preferenze danneggiano in modo sostanziale la garanzia di qualità e i test.
• Le preferenze rendono difficile l'integrazione e la buona interfaccia utente.
• Un buon programma si definisce tale quando fa qualcosa di specifico e lo fa bene.
• Le preferenze trattengono le persone dal correggere i veri errori.
• Le preferenze possono confondere molti utenti.

Ritengo che se si è estremamente disciplinati nell'avere buoni valori predefiniti che semplicemente funzionano invece di aggiungere pigramente preferenze, in modo naturale si conduce l'interfaccia utente complessiva nella giusta direzione. I problemi vengono rilevati attraverso bugzilla o mailing list o test degli utenti, e vanno risolti in un modo diverso dall'aggiungere una preferenza; questo significa che si deve pensare alla corretta interfaccia utente e al modo giusto per risolvere i problemi. Fondamentalmente, utilizzare le preferenze come un cerotto è la radice di molto del male insito nelle interfacce utente.

http://mpt.mirror.theinfo.org/discuss/msgReader$173

• Primo corollario: Ogni collaboratore al progetto cerca di prendere parte al disegno dell'interfaccia, incurante di quanto poco conosca sull'argomento. E se c'è più di un progettista, si ottiene incoerenza, sia nella visione che nel dettaglio. La qualità di un progetto di interfaccia è inversamente proporzionale al numero di progettisti.
• Secondo corollario: Persino quando ci sono progettisti dedicati all'interfaccia, essi non sono ascoltati tanto quanto lo sarebbero in progetti professionali, proprio perché sono progettisti dedicati e non hanno gli strumenti per attuare i loro suggerimenti.

http://ometer.com/features.html

Si prega di non perdere tempo ad inveire contro i programmatori se la caratteristuica desiderata non è ancora stata inserita. Fornire una migliore spiegazione razionale, sì. Accendere fuochi sul fatto che i programmatori devono dire "no" parecchie volte, no. Il progetto fatto da un comitato è di gran lunga peggiore del rifiuto di un paio di correzioni. Come dice Linus (Torvalds), "Se non lo capisci, non perdere tempo a mandarmi e-mail."

Regola speciale di bugzilla: se sposti un bug da WONTFIX (non verrà corretto) o NOTABUG (non è un bug) a REOPENED (riaperto), faresti bene ad aggiungere anche una spiegazione razionale e di qualità. Per vederla in un altro modo: se sei troppo pigro per fare il compito e pensi attraverso la logica del grande schermo, io sono troppo pigro per aggiungere la caratteristica. D'altro canto, le correzioni che arrivano con spiegazioni razionali ben concepite sono spesso applicate immediatamente.

Oltre a dire "no", i programmatori hanno un paio di altri obblighi secondo me:

• In presenza di una buona spiegazione razionale, i programmatori dovrebbero avere la volontà di cambiare idea spesso.
• Se vuoi fornire il tuo insieme di correzioni o la tua distribuzione del software con differenti caratteristiche, il programmatore non dovrebbe lamentarsi.

http://ometer.com/hacking.html

• Usate le mailing list. Se avete domande, ponetele nella lista.
• Nessuno è responsabile. La gente spesso si aspetta che qualcuno sia responsabile di un progetto software libero; oppure si aspetta che venga assegnato loro un compito, e di doverlo completare entro una certa scadenza. Non funziona affatto così. Non si può controllare su cosa gli altri stanno lavorando, e nessuno ti dirà su cosa lavorare, sebbene ci saranno parecchi suggerimenti. Devi tuffarti nel progetto e far accadere le cose.
• Coordinati con gli altri.
• Non esiste risposta alla domanda "quando sarà finito X?" o "la funzionalità X sarà implementata?" La risposta ad entrambe le domande è "quando e se qualcuno farà il lavoro." Se quel qualcuno sei tu, allora conosci la risposta. Se quel qualcuno non sei tu, allora non ti resta che aspettare e vedere.
• Cerca di conoscere la comunità.