Eén van de meest frustrerende ervaringen die een gebruiker van software kan hebben is om een probleemrapport in te sturen om het vervolgens afgehandeld te zien met een korte en onbehulpzame uitleg als “geen bug” of “fout PR”. Evenzo is één van de meest frustrerende ervaringen als ontwikkelaar van software om overspoeld te worden met probleemrapporten die niet echt een probleemrapport zijn maar ondersteuningsverzoeken, of die weinig tot geen informatie bevatten over wat het probleem is en hoe het te reproduceren.
Dit document poogt te beschrijven hoe goede probleemrapporten te schrijven. Wat is een goed probleemrapport? Kort door de bocht is een goed probleemrapport een rapport dat geanalyseerd kan worden en waar snel mee kan worden omgegaan, voor de wederzijdse voldoening van zowel de gebruiker als de ontwikkelaar.
Hoewel de nadruk van dit artikel ligt op probleemrapporten voor FreeBSD, zou het meeste ook in sterke mate op andere softwareprojecten van toepassing moeten zijn.
Merk op dat dit artikel thematisch in plaats van chronologisch is ingedeeld, dus u dient het hele document te lezen alvorens een probleemrapport in te sturen, en het niet als een stapsgewijze tutorial te behandelen.
| Volgende | ||
| Wanneer een probleemrapport te versturen |
Deze en andere documenten kunnen worden gedownload van ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
Lees voor vragen over FreeBSD de documentatie alvorens contact te zoeken
<questions@FreeBSD.org>.
Vragen over deze documentatie kunnen per e-mail naar <doc@FreeBSD.org>.