161215

• 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 : -)

• 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.

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