[gl-como] Scelta di progetto

[pirla]

Ciao a tutti

Il giorno gio, 24/01/2008 alle 20.27 +0100, Flaper87 ha scritto:

> Vi ricordo quale sono i progetti:
> 
>       * QA ("Quality Assurance") Italiano
Questo è decondo me uno dei progetti che al momento merita, insieme al
successivo, l'attenzione e la partecipazione di membri che abbiano
intenzione di aiutare lo sviluppo e l'evoluzione di prodotti OpenSource,
in modo da favorirne la diffusione.

Insieme a Brisa avevamo iniziato, così come abbiamo iniziato tante cose,
ma non siamo riusciti a trasmettere l'entusiasmo agli altri membri e
frequentatori del gl-como.
Per quanto riguarda OpenOffice QA Italiano, l'impegno richiesto è
risultato veramente moderato (e purtroppo nonostante la piccola
richiesta di tempo io ultimamente non ho avuto modo di partecipare) e se
diviso tra più persone risulterebbe molto di meno.
Inoltre, essendo più persone coinvolte, i test possono essere svolti con
maggiore accuratezza.

Legato al progetto di testing delle versioni pre-rilascio ci sarebbe un
altro aspetto del QA che a parer mio è ancora più importante.
Quando abbiamo un problema con un prodotto OpenSource ci scontriamo con
la potenza, ma anche con la disorganizzazione del mondo Open.
Intendo dire che se io riscontro un Bug, e sono sicuro che si tratta di
un Bug, posso notificare gli sviluppatori del problema.
Ho avuto esperienze di fix rilasciate nel giro di ore, ma alle volte i
problemi vengono segnalati ma non si vede la soluzione.
Questo soprattutto in progetti di grandi dimensioni.
La causa di ciò è il meccanismo di raccolta delle notifiche di un
problema (bugzilla o simili).
In tutti questi casi il funzionamento segue questo schema

Un utente riscontra un problema:
        In questo caso può cercare di risolverselo per conto suo e
        diffondere una eventuale soluzione, oppure cercare se qualcuno
        ha già riscontrato il problema, per sfruttare una eventuale
        soluzione.
        Altri però non lo fanno... semplicemente si tengono il problema,
        o semplicemente riavviano sperando che il problema sparisca
        magicamente.
        
Un utente segnala un problema.
        Prima di farlo dovrebbe verificare se qualcuno ha già avuto lo
        stesso problema e magari è stata trovata una soluzione, ma sono
        proprio pochi che lo fanno.
        Il problema inserito nel database assume, in base alle
        informazioni fornite dall'utente, alcune caratteristiche, ma una
        caratteristica sicaramente non è modificabile dall'utente. Cioè
        il baco è UNCONFIRMED.
        Cosa vuol dire? Vuol dire che nessuno ha ancora verificato che
        questo sia un vero problema.
        A questo punto entra in gioco una persona, come me quando l'ho
        fatto in modo intenso che:
      * Cerca nel DB qualcosa di simile (non è facile soprattutto perché
        tutto dovrebbe essere scritto in Inglese)
      * Se trova qualcosa di simile, marca la richiesta come duplicato e
        finisce li
      * Se non trova niente, verifica con l'ultima versione stabile, se
        il problema esiste, e verifica con l'ultima versione di sviluppo
        se il problema esiste.
      * Se il problema è già stato risolto, si può suggerire un
        eventuale aggiornamento e comunque si chiude il caso
      * Se il problema è realmente eistente e si verifica anche
        sull'ultima versione di sviluppo, allora il caso viene passato
        in CONFIRMED.
Solo in questo caso il problema arriva all'attenzione di uno
sviluppatore.

Faccio un esempio... io ho riscontrato un problema con evolution, e non
ho trovato nel sito nessun bug uguale al mio... c'è qualcosa di simile
già segnalato, ma nessuno ha mai segnalato il mio stesso problema. Ci
sono un sacco di pagine trovate con google, ma nessuno ha mai pensato di
segnalarlo in modo ufficiale.
io l'ho fatto e dopo 15 giorni lo stato è ancora unconfirmed.
Ieri forse qualcuno lo ha almeno letto e forse lo verificherà, per
decidere se è da confermare e passare agli sviluppatori o no.

Bene... direi che se il gl-como (o i vari membri) creassero degli
account QA e si prendessero un bug al giorno per cercare di capire se è
da confermare o meno, si avrebbe un gran numero di richieste in più che
sarebbero prese in considerazione, invece di stare li ad aspettare che
qualcun altro lo faccia al posto nostro.

Io penso che sia arrivato il momento di darsi una mossa, come ha detto
Brisa.
Io ho cominciato con QA di OOo e purtroppo adesso ho dovuto mollare il
colpo, ma il mio account è sempre valido e nulla mi vieta ogni tanto di
prendermi un caso ed analizzarlo.
Il motivo per ci ho cominciato è stato il fatto che io ho preso tanto
dall'opensource ed è giunto il momento di restituire qualcosa.
Pensateci anche voi... Non sono richieste competenze avanzate. Se non vi
sentite in grado potete prendere il caso successivo, oppure chiedere
aiuto alla comunità.

>       * Free Translation Project - Sezione Italiana
Andate a vedere anche il sito ILDP (Italian Linux documentation Project)
http://www.pluto.it/ildp/

Anche quì... non voglio fare il figo... ma avevo iniziato
Solo che per me in quel periodo era troppo complicato perché non
conoscevo molto bene l'inglese e tradurre non era sempre facile
Però anche questo potrebbe essere interessante. Traducendo si può
imparare anche qualcosa.

Quindi non so se si nota...
il mio voto è:
  Summer of code di Pirla   +5
  QA di OOo                 +2
  ILDP o traduzioni         +1

-- 
Ciao
        Pirla

Per rispondere in E-mail the (punto) pirla (chiocciola) flashnet.it
*** un bacio ai pupi ***

---> Linux user since yesterday <---
--->     Linux User #389536     <---