UIT The arctic university of Norway > Giellatekno
 

161215

Møte om Bugzilla 15.12.16.

Til stades: Lene, Duommá, Børre, Tomi, Maja, Sjur, Ailo, Trond

Slik vi bruker Bugzilla i dag:

  1. Feilrapportering
  2. Diskusjonsforum
  3. Hugseliste

Feilrapportering

  • kva er ein god feilrapport? kva skal han innehalda?
  • når og korleis kan ei melding lukkast?

Prosedyre for opning:

  1. Ha ein god tittel
  2. Repeter gjerne tittelen som første linje i opningskommentaren
  3. Rapporter slik at det er mogleg å repetere feilen
  4. legg gjerne til ein yaml-test eller annan test som får make check til å feila pga den rapporterte feilen

Prosedyre for lukking:

  1. Beskriv hvordan buggen er fiksa
  2. Test, fortrinnsvis ved å bruka døme frå den opphavlege feilmeldinga.
  3. legg gjerne til ein yaml-test eller annan test som får make check til å feila pga den rapporterte feilen, og som demonstrerer at feilen no er retta
  4. Sett status RESOLVED og FIXED
  5. Få aksept (t.d. av bugrapporterar)
  6. Lukk buggen: sett RESOLVED og C

Allment: skriv slik at andre enn du sjølv forstår det du mener : -)

Diskusjonsforum

  • Lage en ny bugzilla når man ser at diskusjonen kommer på sida av det som er buggens tema.
  • Føre diskusjonen over i et møte når den blir for stor, lenke til møtereferat.
  • Lange lister osv kan sjekkes inn i f.eks. morphology/incoming/ med lenke til dette i bugzillalenke
  • Dokumentasjon av problemfeltet som er lagt inn i Bugzillaen kan etterhvert (etter at det er blitt en møtesak) legges i eget jspwiki-dokument og det linkes til denne.

Hugseliste

  • Gi dem P5 som prioritet, og 'feature request' som alvorlegheit.
  • Bruk filter for å ta dei vekk frå søkjeresultata : -)