On 16/06/10 16:49, Andrea Gasparini wrote:
1. Usabilità. Credo che su questo punto siate tutti d'accordo con me:
A4 è scomodo da usare e molto limitato.
Infatti, il primo punto della mail precedente era: come lo miglioriamo?!
Mettiamo su' una lista di cose da fare (discutiamone, intendo) per
migliorarne il viewer.
Dunque, sicuramente c'è molta strada da fare quanto a interfaccia
utente, ma mi risulta difficile mettermi alla tastiera e decidere di
lavorare all'usabilità, sia perché è un concetto amplissimo, sia perché
il progetto è in fase embrionale. Inoltre l'usabilità la si capisce solo
usandolo, quindi si tratta spesso di piccole cose che scopri per caso,
nel tempo.
Secondo me il modo più produttivo per gestire piccoli miglioramenti (di
usabilità ma non solo) è usare il bug tracker.
Ogni issue che viene aperta è un piccolo forum focalizzato su un
argomento circoscritto; il bug tracker nel suo insieme è la lista di
cose da fare che suggeriva Gas ed è anche un modo per gestire chi sta
facendo cosa.
Per esempio:
Un esempio banale è rappresentato dal fatto che non è possibile
saltare alla slide X senza dover passare dalle slide precedenti.
Questa è una perfetta RFE.
La metterei sul bug tracker e lì discuterei di: se la vogliamo
implementare, come dovrebbe essere fatta l'interfaccia, come la si
implementa, chi la fa.
Quindi secondo me a livello minimale l'usabilità va gestita postando un
bug quando ci si accorge che qualcosa non va. Questa è una cosa che
possiamo fare tutti; poi se qualcuno vuole dedicarsi in maniera più
approfondita a questo aspetto naturalmente può farlo. Anche in questo
caso probabilmente il modo più pratico di farlo è segnare sul bug
tracker i problemi riscontrati e fare triage di quelli già presenti.
Inoltre, mentre è difficile sviluppare "l'usabilità" in senso astratto,
è ben più facile guardare sul bug tracker se c'è una cosa sui cui
lavorare. Quindi è anche un modo di indirizzare il lavoro di tutti verso
quelle che si considerano le priorità del momento.
2. Stabilità. Il software è stabile? Funziona in tutte le condizioni?
Sembra di sì, ma come possiamo esserne sicuri? Vi ricordo che non
abbiamo neanche una riga di test suite e gli sforzi messi nel QA sono
pari a zero. :-)
Ecco, da questo punto di vista io sono sempre stato un grande fan degli
unit test.
Come su altre questioni di infrastruttura, mi affido a chi ha più
esperienza di me in Python.
Comunque direi che dovremmo avere:
- infrastruttura per unit test (e che sia facile aggiungere un test una
volta che il tutto funziona)
- gestione della copertura per vedere se ci sono parti di codice non testate
- infrastruttura per testare la GUI (il branch con LDTP già su launchpad)
- infrastuttura per testare il rendering su Cairo (idee?)
- una politica sulla copertura (io sarei per: copertura al 100% e il
nuovo codice deve avere i test prima di essere mergiato in trunk)
Per questi motivi, vi chiederei di frenare un'attimo. Non abbiamo
alcun motivo di andare di fretta, ma anzi abbiamo ragione di fermarci.
Non mi sembra necessario.
Procederei piuttosto ad usare i feature branch come abbiamo fatto sinora.
Eventualmente decidendo una politica ufficiale tipo (ad esempio):
- tutto il codice deve passare da un branch prima di entrare in trunk
- tutti i branch devono essere sottoposti a review
- la review deve durare almeno XX tempo per dare a tutti la possibilità
di vedere cosa succede.
In questo modo chiunque è libero di sviluppare ciò che vuole (tanto è su
un branch) ed eventuali problemi di usabilità, stabilità, testabilità
possono essere intercettati in fase di review senza rompere il trunk.
On 16/06/10 15:49, Andrea Corbellini wrote:
Vi ricordo inoltre che abbiamo anche due
applicazioni concorrenti (Prezi e un'altro)
Ah sì? E non mi dite niente? :-)
Qual è l'altro?
Ma piuttosto che discutere queste cose, cerchiamo di essere pragmatici,
comincio a proporre e mi dite che ne pensate,specificate meglio,
aggiungete o cancellate cose:
È tardi e ho scritto già troppo.
Scusa ma a questo rispondo poi con calma domani.
ciao!
A.
_______________________________________________
Mailing list: https://launchpad.net/~a4-dev
Post to : a4-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~a4-dev
More help : https://help.launchpad.net/ListHelp
