diff --git a/nl_NL.ISO8859-1/articles/Makefile b/nl_NL.ISO8859-1/articles/Makefile
index 5601290990..130eace23a 100644
--- a/nl_NL.ISO8859-1/articles/Makefile
+++ b/nl_NL.ISO8859-1/articles/Makefile
@@ -6,8 +6,7 @@
SUBDIR =
SUBDIR+= contributing
SUBDIR+= explaining-bsd
-
-# ROOT_SYMLINKS+= new-users
+SUBDIR+= problem-reports
DOC_PREFIX?= ${.CURDIR}/../..
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
diff --git a/nl_NL.ISO8859-1/articles/problem-reports/Makefile b/nl_NL.ISO8859-1/articles/problem-reports/Makefile
new file mode 100644
index 0000000000..081f20e0f8
--- /dev/null
+++ b/nl_NL.ISO8859-1/articles/problem-reports/Makefile
@@ -0,0 +1,19 @@
+#
+# $FreeBSD$
+#
+# Article: Writing FreeBSD Problem Reports
+
+DOC?= article
+
+FORMATS?= html
+WITH_ARTICLE_TOC?= YES
+
+INSTALL_COMPRESSED?=gz
+INSTALL_ONLY_COMPRESSED?=
+
+SRCS= article.sgml
+
+URL_RELPREFIX?= ../../../..
+DOC_PREFIX?= ${.CURDIR}/../../..
+
+.include "${DOC_PREFIX}/share/mk/doc.project.mk"
diff --git a/nl_NL.ISO8859-1/articles/problem-reports/article.sgml b/nl_NL.ISO8859-1/articles/problem-reports/article.sgml
new file mode 100644
index 0000000000..9d207e21ce
--- /dev/null
+++ b/nl_NL.ISO8859-1/articles/problem-reports/article.sgml
@@ -0,0 +1,1336 @@
+<!--
+ $FreeBSD$
+ %SOURCE% en_US.ISO8859-1/articles/problem-reports/article.sgml
+ %SRCID% 1.60
+-->
+
+<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
+<!ENTITY % articles.ent PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Articles Entity Set//EN">
+%articles.ent;
+]>
+
+
+<article lang="nl">
+ <articleinfo>
+ <title>Probleemrapporten voor &os; schrijven</title>
+
+ <legalnotice id="trademarks" role="trademarks">
+ &tm-attrib.freebsd;
+ &tm-attrib.cvsup;
+ &tm-attrib.ibm;
+ &tm-attrib.intel;
+ &tm-attrib.sparc;
+ &tm-attrib.sun;
+ &tm-attrib.general;
+ </legalnotice>
+
+ <abstract>
+ <para>Dit artikel beschrijft hoe een probleemrapport het beste
+ geformuleerd en naar het &os; Project verzonden kan
+ worden.</para>
+
+ <para><emphasis>Vertaald door René Ladan</emphasis>.</para>
+ </abstract>
+
+ <authorgroup>
+ <author>
+ <firstname>Dag-Erling</firstname>
+ <surname>Smørgrav</surname>
+ <contrib>Bijgedragen door </contrib>
+ </author>
+
+ <author>
+ <firstname>Mark</firstname>
+ <surname>Linimon</surname>
+ </author>
+ </authorgroup>
+ </articleinfo>
+
+ <indexterm><primary>probleemrapporten</primary></indexterm>
+
+ <section id="pr-intro">
+ <title>Introductie</title>
+
+ <para>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 <quote>geen bug</quote> of <quote>fout
+ PR</quote>. 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.</para>
+
+ <para>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.</para>
+
+ <para>Hoewel de nadruk van dit artikel ligt op probleemrapporten
+ voor &os;, zou het meeste ook in sterke mate op andere
+ softwareprojecten van toepassing moeten zijn.</para>
+
+ <para>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.</para>
+ </section>
+
+ <section id="pr-when">
+ <title>Wanneer een probleemrapport te versturen</title>
+
+ <para>Er zijn vele soorten problemen, die niet allemaal geschikt
+ zijn voor een probleemrapport. Natuurlijk is niemand perfect dus
+ zal het soms voorkomen dat u overtuigd bent dat u een bug in een
+ programma heeft gevonden terwijl u in feite de syntaxis voor een
+ commando verkeerd begrepen heeft of een typefout in een
+ instellingenbestand gemaakt heeft (hoewel dat soms zelf al op
+ slechte documentatie of slechte foutafhandeling in de applicatie
+ kan wijzen). Er zijn nog steeds veel gevallen waarin het insturen
+ van een probleemrapport duidelijk <emphasis>niet</emphasis> de
+ juiste handeling is, en het alleen tot frustratie bij uzelf en de
+ ontwikkelaars leidt. Omgekeerd zijn er gevallen waarin het juist
+ kan zijn om een probleemrapport in te sturen over iets anders dan
+ een bug—bijvoorbeeld voor een verbetering of een
+ mogelijkheidsverzoek.</para>
+
+ <para>Dus hoe wordt bepaald of iets wel of niet een bug is? Een
+ eenvoudige vuistregel is dat uw probleem <emphasis>geen</emphasis>
+ bug is als het als een vraag kan worden uitgedrukt (meestal van de
+ vorm <quote>Hoe doe ik X?</quote> of <quote>Waar kan ik Y
+ vinden?</quote>). Het is niet altijd zo zwart-wit, maar de
+ vraagregel gaat in de meeste gevallen op. Overweeg, als u een
+ antwoord zoekt, om uw vraag aan de &a.questions; te
+ stellen.</para>
+
+ <para>Enkele gevallen waar het juist kan zijn om een probleemrapport
+ in te sturen over iets dat geen bug is zijn:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>Verzoeken om verbetering van mogelijkheden. Het is over
+ het algemeen een goed idee om deze op de mailinglijsten te
+ uiten alvorens een probleemrapport in te sturen.</para>
+ </listitem>
+
+ <listitem>
+ <para>Meldingen van updates aan extern onderhouden software
+ (over het algemeen ports, maar ook extern onderhouden
+ componenten van het basissysteem zoals BIND of verscheidene
+ gereedschappen van GNU).</para>
+
+ <para>Voor onbeheerde ports (<makevar>MAINTAINER</makevar> bevat
+ <literal>ports@FreeBSD.org</literal>) kan zo'n updatemelding
+ opgepakt worden door een geïnteresseerde committer, of u
+ kunt gevraagd worden om een patch aan te leveren om de port
+ bij te werken; door dit van te voren aan te bieden verhoogt u
+ in sterke mate de kans dat de port binnen een redelijk
+ tijdsbestek wordt bijgewerkt.</para>
+
+ <para>Als de port beheerd wordt, zijn PR's die nieuwe
+ stroomopwaartse uitgaven aankondigen niet erg nuttig aangezien
+ ze aanvullend werk voor de committers genereren, en
+ waarschijnlijk weet de beheerder al dat er een nieuwe versie
+ uit is, ze hebben er waarschijnlijk met de ontwikkelaars aan
+ gewerkt, ze zijn waarschijnlijk regressietesten aan het
+ uitvoeren, enzovoorts.</para>
+
+ <para>In beide gevallen zal het volgen van het proces zoals
+ beschreven in het <ulink
+ url="&url.books.porters-handbook;/port-upgrading.html">
+ Porters Handboek</ulink> tot de beste resultaten leiden. (U
+ bent misschien ook geïnteresseerd in <ulink
+ url="&url.articles.contributing-ports;/article.html">
+ Bijdragen aan de &os; Portscollectie</ulink>.)</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>Een bug die niet reproduceerbaar is kan zelden gerepareerd
+ worden. Als een bug slechts eenmalig voorkwam en u deze niet kunt
+ reproduceren, en het bij niemand anders lijkt voor te komen, dan
+ bestaat de kans dat geen van de ontwikkelaars het kan reproduceren
+ of kan uitzoeken wat er mis is. Dit betekent niet dat het niet
+ gebeurde, maar wel dat de kans dat uw probleemrapport ooit tot een
+ reparatie leidt erg klein is. Om het allemaal erger te maken,
+ worden dit soort bugs vaak veroorzaakt door falende harde schijven
+ of oververhitte processoren — u dient altijd te proberen om
+ deze oorzaken, indien mogelijk, uit te sluiten voordat u een PR
+ instuurt.</para>
+
+ <para>Vervolgens, om te besluiten aan wie u uw probleemrapport dient
+ te sturen, moet u weten dat de software waaruit &os; bestaat uit
+ verschillende elementen is opgebouwd:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>Code in het basissysteem die geschreven is en onderhouden
+ wordt door &os;-vrijwilligers, zoals de kernel, de
+ C-bibliotheek, en de apparaatstuurprogramma's (gecategoriseerd
+ als <literal>kern</literal>); de binaire hulpmiddelen
+ (<literal>bin</literal>); de handleidingpagina's en
+ documentatie (<literal>docs</literal>); en de webpagina's
+ (<literal>www</literal>). Alle bugs in deze gebieden dienen
+ aan de &os;-ontwikkelaars gerapporteerd te worden.</para>
+ </listitem>
+
+ <listitem>
+ <para>Code in het basissysteem die geschreven is en onderhouden
+ wordt door anderen, en in &os; is geïmporteerd en
+ aangepast. Voorbeelden zijn <application>bind</application>,
+ &man.gcc.1;, en &man.sendmail.8;. De meeste bugs in deze
+ gebieden dienen aan de &os;-ontwikkelaars gerapporteerd te
+ worden; maar in sommige gevallen kan het zijn dat ze aan de
+ originele auteurs gerapporteerd moeten worden als de problemen
+ niet specifiek voor &os; zijn. Gewoonlijk vallen deze bugs in
+ ofwel de categorie <literal>bin</literal> ofwel de categorie
+ <literal>gnu</literal>.</para>
+ </listitem>
+
+ <listitem>
+ <para>Individuele applicaties die niet in het basissysteem
+ zitten maar in plaats daarvan deel zijn van de Portscollectie
+ van &os; (categorie <literal>ports</literal>). De meeste van
+ deze applicaties zijn niet geschreven door &os;-ontwikkelaars;
+ wat &os; biedt is slechts een raamwerk om de applicatie te
+ installeren. Daarom dient u alleen een probleem aan de
+ &os;-ontwikkelaars te rapporteren als u gelooft dat het
+ probleem specifiek voor &os; is; anders dient u het aan de
+ auteurs van de software te rapporteren.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>Daarna dient u vast te stellen of het probleem actueel is. Er
+ zijn maar weinig dingen die een ontwikkelaar meer irriteren dan
+ het ontvangen van een probleemrapport over een bug die reeds
+ gerepareerd is.</para>
+
+ <para>Als het probleem in het basissysteem zit, dient u eerst het
+ FAQ-gedeelte over <ulink
+ url="&url.books.faq;/introduction.html#LATEST-VERSION">
+ &os;-versies</ulink> te lezen als u niet reeds bekend bent met
+ het onderwerp. Het is niet mogelijk voor &os; om problemen in
+ iets anders dan bepaalde recente takken van het basissysteem op te
+ lossen, dus leidt het insturen van een bug-rapport over een oudere
+ versie waarschijnlijk alleen tot het advies van een ontwikkelaar
+ om naar een ondersteunde versie bij te werken om te kijken of het
+ probleem nog steeds voorkomt. Het Security Officer Team
+ onderhoudt de <ulink url="&url.base;/security/">lijst van
+ ondersteunde versies</ulink>.</para>
+
+ <para>Als het probleem in een port zit, moet u uw Portscollectie
+ eerst naar de laatste versie bijwerken en kijken of het probleem
+ nog steeds van toepassing is. Wegens de hoge snelheid waarmee
+ deze applicaties veranderen, is het onhaalbaar voor &os; om iets
+ anders dan de allernieuwste versies te ondersteunen, problemen met
+ oudere versies van applicaties kunnen simpelweg niet worden
+ opgelost.</para>
+ </section>
+
+ <section id="pr-prep">
+ <title>Voorbereidingen</title>
+
+ <para>Een goede regel is om altijd een vooronderzoek te doen voordat
+ u een probleemrapport ingestuurd. Misschien is uw probleem reeds
+ gerapporteerd; misschien wordt het besproken op de mailinglijsten,
+ of gebeurde dat recentelijk; misschien is het al gerepareerd in
+ een nieuwere versie dan die u draait. Om deze redenen dient u
+ alle voor de hand liggende plaatsen te controleren voordat u uw
+ probleemrapport instuurt. Voor &os; betekent dit:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>De &os;-lijst van
+ <ulink url="&url.books.faq;/index.html">Veelgestelde
+ Vragen</ulink> (FAQ). De FAQ probeert antwoord te geven op
+ een breed scala aan vragen, zoals die die betrekking hebben op
+ <ulink url="&url.books.faq;/hardware.html">compatibiliteit van
+ hardware</ulink>,
+ <ulink url="&url.books.faq;/applications.html">
+ gebruikersapplicaties</ulink>, en
+ <ulink url="&url.books.faq;/kernelconfig.html">
+ kernelconfiguratie</ulink>.</para>
+ </listitem>
+
+ <listitem>
+ <para>De
+ <ulink
+ url="&url.books.handbook;/eresources.html#ERESOURCES-MAIL">
+ mailinglijsten</ulink>—als u niet geabonneerd bent,
+ gebruik dan <ulink
+ url="http://www.FreeBSD.org/search/search.html#mailinglists">
+ de doorzoekbare archieven</ulink> op de &os;-website. Als
+ uw probleem niet op de lijsten bediscussieerd is, kunt u
+ proberen om er een bericht over te posten en enkele dagen
+ wachten om te zien of iemand iets kan zien wat u misschien
+ over het hoofd heeft gezien.</para>
+ </listitem>
+
+ <listitem>
+ <para>Optioneel, het gehele web—gebruik uw favoriete
+ zoekmachine om referenties naar uw probleem te vinden. U kunt
+ zelfs hits krijgen van gearchiveerde mailinglijsten of
+ nieuwsgroepen die u niet kende of waarvan u er niet aan had
+ gedacht om die te doorzoeken.</para>
+ </listitem>
+
+ <listitem>
+ <para>Vervolgens, de doorzoekbare
+ <ulink url="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query">
+ &os; PR-database</ulink> (GNATS). Tenzij uw probleem recent
+ of obscuur is, bestaat er een redelijke kans dat het reeds
+ gerapporteerd is.</para>
+ </listitem>
+
+ <listitem>
+ <para>Het belangrijkste is dat u probeert te controleren of
+ bestaande documentatie in de bronnen uw probleem
+ bespreekt.</para>
+
+ <para>Voor de basis-&os;-code dient u zorgvuldig de inhoud van
+ het bestand <filename>/usr/src/UPDATING</filename> op uw
+ systeem of de laatste versie ervan op <ulink
+ url="http://www.FreeBSD.org/cgi/cvsweb.cgi/src/UPDATING"></ulink>
+ te bestuderen. (Dit is essentiële informatie als u van
+ de ene naar een andere versie bijwerkt—in het bijzonder
+ als u naar de tak &os.current; bijwerkt.)</para>
+
+ <para>Als het probleem echter zit in iets wat als deel van de
+ &os; Portscollectie was geïnstalleerd, dan dient u
+ <filename>/usr/ports/UPDATING</filename> (voor individuele
+ ports) of <filename>/usr/ports/CHANGES</filename> (voor
+ veranderingen die de gehele Portscollectie beïnvloeden)
+ te raadplegen.
+ <ulink url="http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/UPDATING"></ulink>
+ en
+ <ulink url="http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/CHANGES"></ulink>
+ zijn ook beschikbaar via CVSweb.</para>
+ </listitem>
+ </itemizedlist>
+ </section>
+
+ <section id="pr-writing">
+ <title>Het probleemrapport schrijven</title>
+
+ <para>Nu u besloten heeft dat uw probleem een probleemrapport
+ verdiend, en het een probleem met &os; is, is het tijd om het
+ eigenlijke probleemrapport te schrijven. Voordat het mechanisme
+ van het programma dat gebruikt wordt om PR's aan te maken en in te
+ sturen wordt behandeld, zijn hier wat tips en trucs die ervoor
+ zorgen dat uw PR het meest effectief is.</para>
+
+ <section>
+ <title>Tips en trucs voor het schrijven van een goed
+ probleemrapport</title>
+
+ <itemizedlist>
+ <listitem>
+ <para><emphasis>Laat de regel <quote>Synopsis</quote> niet
+ leeg.</emphasis> De PR's gaan zowel naar een mailinglijst
+ die over de gehele wereld wordt verspreid (waar de
+ <quote>Synopsis</quote> wordt gebruikt voor de
+ <literal>Onderwerp:</literal>-regel), als in een database.
+ Iedereen die later de database op samenvatting doorzoekt, en
+ een PR met een lege onderwerpsregel aantreft, zal het
+ waarschijnlijk gewoon overslaan. Onthoud dat PR's in deze
+ database blijven staan totdat iemand ze sluit; een anoniem
+ PR zal slechts in de massa opgaan.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>Voorkom het gebruik van een zwakke
+ <quote>Synopsis</quote>-regel.</emphasis> U mag niet
+ aannemen dat iemand die uw PR leest enige achtergrondkennis
+ van uw inzending heeft, dus des meer u biedt, des te beter.
+ Op welk deel van het systeem heeft het probleem betrekking?
+ Ziet u het probleem alleen tijdens het installeren, of
+ tijdens het draaien? Ter illustratie, in plaats van
+ <literal>Synopsis: portupgrade is broken</literal>, zie
+ hoeveel informatiever dit lijkt: <literal>Synopsis: port
+ pors-mgmt/portupgrade coredumps on -current</literal>.
+ (In het geval van ports is het bijzonder behulpzaam om zowel
+ de categorie als de portnaam in de
+ <quote>Synopsis</quote>-regel te vermelden.)</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>Als u een patch heeft, zeg dat dan.</emphasis>
+ Het is veel waarschijnlijker dat een PR met daarin een patch
+ bekeken wordt dan een PR zonder patch. Als u een patch
+ bijsluit, plaats dan de tekst <literal>[patch]</literal>
+ (inclusief de haken) aan het begin van de
+ <quote>Synopsis</quote>. (Alhoewel het niet verplicht is om
+ die exacte tekst te gebruiken, is dat per conventie degene
+ die gebruikt wordt.)</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>Als u een onderhouder bent, zeg dat
+ dan.</emphasis> Als u een deel van de broncode onderhoudt
+ (bijvoorbeeld een port), kunt u overwegen om de tekst
+ <literal>[maintainer update]</literal> (inclusief de haken)
+ aan het begin van de onderwerpsregel te plaatsen, en dient u
+ zeker de <quote>Class</quote> van uw PR op
+ <literal>maintainer-update</literal> te zetten. Op deze
+ manier hoeft de committer die uw PR behandelt dit niet te
+ controleren.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>Ben specifiek.</emphasis> Des te meer
+ informatie u aanlevert over wat voor probleem u heeft, des
+ te groter is de kans dat u een antwoord krijgt.</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>Vermeld de versie van &os; die u draait (hier is een
+ plaats voor, zie hieronder) en op welke architectuur dat
+ is. U dient aan te geven of u een uitgave draait
+ (bijvoorbeeld een CD-ROM of een download), of een
+ systeem dat met &man.cvsup.1; wordt onderhouden (en
+ zoja, hoe recentelijk u dat heeft bijgewerkt). Als u de
+ tak &os.current; volgt, is dat het allereerste wat
+ iemand zal vragen, omdat reparaties (in het bijzonder
+ voor opvallende problemen) de neiging hebben om snel
+ gecommit te worden, en gebruikers van &os.current;
+ worden geacht om hun zaken bij te houden.</para>
+ </listitem>
+
+ <listitem>
+ <para>Vermeld welke globale opties u in uw
+ <filename>make.conf</filename> heeft gespecificeerd.
+ Noot: het specificeren van <literal>-O2</literal> en
+ hoger aan &man.gcc.1; staat in veel situaties als
+ bug-gevoelig bekend. Hoewel de &os;-ontwikkelaars
+ patches zullen accepteren, zijn ze over het algemeen
+ niet bereid om zulke gevallen te onderzoeken vanwege een
+ simpel gebrek aan tijd en vrijwilligers, en zullen ze in
+ plaats hiervan antwoorden met dat dit gewoon niet
+ ondersteund is.</para>
+ </listitem>
+
+ <listitem>
+ <para>Als het een probleem met de kernel betreft, reken er
+ dan op om de volgende informatie aan te leveren. (U
+ hoeft deze niet standaard bij te sluiten, wat alleen de
+ database opvult, maar u dient uittreksel bij te sluiten
+ die u relevant acht):</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>uw kernelconfiguratie (inclusief welke
+ hardware-apparaten u heeft
+ geïnstalleerd)</para>
+ </listitem>
+ <listitem>
+ <para>of u wel of niet debug-opties aan heeft staan
+ (zoals <literal>WITNESS</literal>), en zoja, of het
+ probleem zich blijft voordoen als u de optie
+ omkeert</para>
+ </listitem>
+
+ <listitem>
+ <para>een backtrace, als er een was gegenereerd</para>
+ </listitem>
+
+ <listitem>
+ <para>het feit dat u
+ <filename>/usr/src/UPDATING</filename> heeft
+ gelezen en dat uw probleem daar niet staat vermeld
+ (iemand gaat er geheid naar vragen)</para>
+ </listitem>
+
+ <listitem>
+ <para>of u wel of niet op het draaien van een andere
+ kernel kunt terugvallen (dit is om problemen
+ gerelateerd aan hardware zoals falende schijven en
+ oververhitte CPU's uit te sluiten, welke zich als
+ kernelprobleem kunnen vermommen)</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ <listitem>
+ <para>Als het een probleem met de ports betreft, reken er
+ dan op om de volgende informatie aan te leveren. (U
+ hoeft deze niet standaard bij te sluiten, wat alleen de
+ database opvult, maar u dient uittreksels bij te sluiten
+ die u relevant acht):</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>welke ports u heeft geïnstalleerd</para>
+ </listitem>
+
+ <listitem>
+ <para>alle omgevingsvariabelen die de standaardwaarden
+ in <filename>bsd.port.mk</filename> overschrijven,
+ zoals <makevar>PORTSDIR</makevar></para>
+ </listitem>
+
+ <listitem>
+ <para>het feit dat u
+ <filename>/usr/ports/UPDATING</filename> heeft
+ gelezen en dat uw probleem daar niet staat vermeld
+ (iemand gaat er geheid naar vragen)</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>Voorkom vage verzoeken voor
+ mogelijkheden.</emphasis> PR's van de vorm <quote>iemand
+ moet echt iets dat zus-en-zo doet implementeren</quote>
+ leveren minder waarschijnlijk resultaat op dan zeer
+ specifieke verzoeken. Onthoud dat de broncode voor iedereen
+ beschikbaar is, dus als u een mogelijkheid wilt is de beste
+ manier om het erin te krijgen aan het werk te gaan! Neem
+ ook het feit in overweging dat veel van dit soort dingen
+ beter op <literal>freebsd-questions</literal> besproken
+ kunnen worden dan als een regel in de PR-database, zoals
+ hierboven besproken.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>Verzeker u ervan dat niemand anders reeds een
+ soortgelijk PR heeft ingestuurd.</emphasis> Alhoewel dit al
+ hierboven genoemd is, is het het herhalen hier waard. Het
+ duurt slechts een minuut of twee om de webgebaseerde
+ zoekmachine op <ulink
+ url="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query">
+ </ulink> te gebruiken. (Natuurlijk vergeet iedereen dit zo
+ nu en dan.)</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>Voorkom controversiële
+ verzoeken.</emphasis> Als uw PR een gebied behandelt dat in
+ het verleden controversieel was, dient u waarschijnlijk
+ bereid te zijn om niet alleen patches, maar ook een
+ verklaring waarom de patches <quote>Het Juiste Ding Om Te
+ Doen</quote> zijn aan te leveren. Zoals hierboven
+ vermeld, is het zorgvuldig doorzoeken van de mailinglijsten
+ door gebruik te maken van de archieven op <ulink
+ url="http://www.FreeBSD.org/search/search.html#mailinglists">
+ </ulink> altijd een goede voorbereiding.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>Ben beleefd.</emphasis> Bijna iedereen die aan
+ uw PR zal werken is een vrijwilliger. Niemand houdt ervan
+ om te horen dat ze iets moeten doen wat ze al aan het doen
+ zijn voor een andere motivatie dan geld. Dit is iets goeds
+ om altijd in de gaten te houden bij Open Source
+ projecten.</para>
+ </listitem>
+ </itemizedlist>
+ </section>
+
+ <section>
+ <title>Voordat u begint</title>
+
+ <para>Als u het programma &man.send-pr.1; gebruikt, zorg er dan
+ voor dat uw omgevingsvariabele <envar>VISUAL</envar> (of
+ <envar>EDITOR</envar> als <envar>VISUAL</envar> niet is
+ ingesteld) op iets zinnigs is ingesteld.</para>
+
+ <para>U dient er ook zeker van te zijn dat het afleveren van mail
+ goed werkt. &man.send-pr.1; gebruikt mailberichten voor het
+ insturen en volgen van probleemrapporten. Als u geen
+ mailberichten kunt posten op de machine waarop u &man.send-pr.1;
+ draait, zal uw probleemrapport de GNATS-database niet bereiken.
+ Zie voor details over het opzetten van mail op &os; het
+ hoofdstuk <quote>Elektronische post</quote> van het &os;
+ Handboek op
+ <ulink url="http://www.FreeBSD.org/doc/nl_NL.ISO8859-1/books/handbook/mail.html"></ulink>.</para>
+
+ <para>Verzeker u ervan dat uw mailprogramma het bericht onderweg
+ naar GNATS niet vermangelt. In het bijzonder zal elke patch die
+ u instuurt onbruikbaar worden, als uw mailer automatisch regels
+ afbreekt, tabs in spaties verandert, of nieuwe-regel-tekens
+ escapet. Voor de tekstgedeelten vragen wij u echter om
+ handmatig regels rond de 70 tekens af te breken, zodat de
+ webversie van het PR leesbaar is.</para>
+
+ <para>Dezelfde soort overwegingen gelden als u het <ulink
+ url="&url.base;/send-pr.html">webgebaseerde
+ PR-instuurformulier</ulink> in plaats van &man.send-pr.1;
+ gebruikt. Merk op dat knip-en-plakbewerkingen hun eigen
+ bijwerkingen op tekstopmaak kunnen hebben. In bepaalde gevallen
+ kan het nodig zijn om &man.uuencode.1; te gebruiken om er zeker
+ van te zijn dat patches ongewijzigd aankomen.</para>
+
+ <para>Ten slotte, als uw inzending lang is, dient u uw werk
+ offline voor te bereiden zodat er niets verloren gaat indien er
+ zich een probleem met het inzenden ervan voordoet. Dit kan in
+ het bijzonder een probleem zijn met het <ulink
+ url="&url.base;/send-pr.html">webformulier</ulink>.</para>
+ </section>
+
+ <section>
+ <title>Patches of bestanden bijvoegen</title>
+
+ <para>Het volgende geldt voor het versturen van PR's via
+ email:</para>
+
+ <para>Het programma &man.send-pr.1; heeft voorzieningen voor het
+ bijvoegen van bestanden aan een probleemrapport. U kunt zoveel
+ bestanden bijvoegen als u wilt op voorwaarde dat elk bestand een
+ unieke basisnaam (i.e. de naam van het bestand zelf, zonder het
+ pad) heeft. Gebruik de opdrachtregeloptie <option>-a</option>
+ om de namen van de bij te voegen bestanden te
+ specificeren:</para>
+
+<screen>&prompt.user; <userinput>send-pr -a /var/run/dmesg -a /tmp/fouten</userinput></screen>
+
+ <para>Maakt u zich geen zorgen over binaire bestanden, deze worden
+ automatisch gecodeerd zodat ze de mail-agent niet
+ verontrusten.</para>
+
+ <para>Als u een patch bijvoegt, gebruik dan de optie
+ <option>-c</option> of <option>-u</option> van &man.diff.1; om
+ een context- of verenigde diff (verenigd is geprefereerd) aan te
+ maken, en zorg ervoor dat u de exacte revisienummers uit CVS
+ specificeert van de bestanden die u heeft gewijzigd zodat de
+ ontwikkelaars die uw rapport lezen ze gemakkelijk kunnen
+ toepassen. Voor problemen met de kernel of de
+ basisgereedschappen is een patch tegen &os.current; (de CVS-tak
+ HEAD) geprefereerd aangezien alle nieuwe code eerst daar
+ toegepast en getest dient te worden. Nadat het voldoende of
+ substantieel is getest, wordt de code samengevoegd of gemigreerd
+ naar de tak &os.stable;.</para>
+
+ <para>Als u een patch inline in plaats van als bijlage bijvoegt,
+ merk dan op dat het meest voorkomende probleem de neiging is van
+ sommige email-programma's om tabs als spaties weer te geven, wat
+ alles dat bedoeld was als deel van een Makefile volledig
+ ruineert.</para>
+
+ <para>Stuur geen patches als bijlagen door gebruik te maken van
+ <command>Content-Transfer-Encoding: quoted-printable</command>.
+ Dit zal karakter-escaping uitvoeren en de gehele patch
+ waardeloos maken.</para>
+
+ <para>Merk ook op dat hoewel het over het algemeen goed is om
+ kleine patches in een PR op te nemen—in het bijzonder als
+ ze het probleem dat in het PR beschreven is oplossen—grote
+ patches en in het bijzonder nieuwe code waarvoor
+ substantiële review nodig kan zijn voordat het gecommit
+ wordt op een web- of FTP-server geplaatst dient te worden, en de
+ URL in plaats van de patch bij het PR gevoegd dient te worden.
+ Patches in email hebben de neiging om gemangeld te worden, in
+ het bijzonder wanneer GNATS erbij betrokken is, en hoe groter de
+ patch, des te moeilijker het is voor geïnteresseerde
+ partijen om het te ontrafelen. Ook stelt het posten van een
+ patch op het web u in staat om het te wijzigen zonder dat het
+ nodig is om de gehele patch opnieuw in te zenden als een
+ vervolgbericht op het originele PR. Ten slotte vergroten grote
+ patches simpelweg de omvang van de database, aangezien gesloten
+ PR's niet worden verwijderd maar in plaats daarvan worden
+ bewaard en simpelweg als <literal>closed</literal> worden
+ gemarkeerd.</para>
+
+ <para>U dient ook te weten dat tenzij u het expliciet in uw PR of
+ in de patch zelf vermeld, dat van alle patches die u instuurt
+ wordt aangenomen dat ze onder dezelfde licentietermen vallen als
+ het originele bestand dat u heeft gewijzigd.</para>
+ </section>
+
+ <section>
+ <title>Het sjabloon invullen</title>
+
+ <para>De volgende sectie heeft alleen betrekking op de
+ email-methode:</para>
+
+ <para>Wanneer u &man.send-pr.1; draait, wordt er een sjabloon aan
+ u gepresenteerd. Het sjabloon bestaat uit een lijst met velden,
+ waarvan sommige al zijn ingevuld, en waarvan bij anderen staat
+ uitgelegd wat de bedoeling is of wat acceptabele waarden zijn.
+ Maakt u zich geen zorgen over het commentaar, deze worden
+ automatisch verwijderd wanneer u ze niet wijzigt of ze zelf
+ verwijdert.</para>
+
+ <para>Bovenaan het sjabloon, onder de regels met
+ <literal>SEND-PR:</literal>, staan de email-koppen. U hoeft
+ deze normaalgesproken niet te wijzigen, tenzij u het
+ probleemrapport vanaf een machine of account verstuurt die wel
+ mail kan versturen maar niet kan ontvangen; in dat geval wilt u
+ waarschijnlijk de velden <literal>From:</literal> en
+ <literal>Reply-To:</literal> op uw echte emailadres instellen.
+ U kunt uzelf (of iemand anders) een carbonkopie van het
+ probleemrapport versturen door één of meer
+ emailadressen aan de kop <literal>Cc:</literal> toe te
+ voegen.</para>
+
+ <para>In het email-sjabloon vindt u de volgende twee velden van
+ één regel:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para><emphasis>Submitter-Id:</emphasis> Verander dit niet.
+ De standaardwaarde <literal>current-users</literal> is
+ juist, zelfs als u &os.stable; draait.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>Confidential:</emphasis> Dit is vooraf
+ ingevuld met <literal>no</literal>. Het heeft geen zin om
+ dit te veranderen aangezien er geen vertrouwelijk &os;
+ probleemrapport bestaat—de PR-database wordt
+ wereldwijd gedistribueerd door
+ <application>CVSup</application>.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>De volgende sectie beschrijft velden die zowel in de
+ email-interface als in de <ulink
+ url="&url.base;/send-pr.html">webinterface</ulink>
+ voorkomen:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para><emphasis>Originator:</emphasis>
+ Specificeer hier alstublieft uw echte naam, eventueel
+ gevolgd door uw emailadres in punthaken. In de
+ email-interface wordt dit normaalgesproken vooraf ingevuld
+ met het <literal>gecos</literal>-veld van de huidige
+ aangemelde gebruiker.</para>
+
+ <note>
+ <para>Het emailadres dat u gebruikt wordt publieke
+ informatie en kan in de handen van spammers vallen. U
+ dient òfwel maatregelen te treffen om spam af te
+ handelen, òf een tijdelijk emailaccount te
+ gebruiken. Merk op dat als u een in het geheel ongeldig
+ emailaccount gebruikt, wij u geen vragen over uw PR kunnen
+ stellen.</para>
+ </note>
+
+ </listitem>
+
+ <listitem>
+ <para><emphasis>Organization:</emphasis> Alles waarvan u
+ vrolijk wordt. Dit veld wordt niet voor iets significants
+ gebruikt.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>Synopsis:</emphasis> Vul hier een korte en
+ accurate beschrijving van het probleem in. De samenvatting
+ wordt gebruikt als het onderwerp van de email van het
+ probleemrapport, en wordt gebruikt in lijsten en
+ samenvattingen van probleemrapporten; probleemrapporten met
+ een obscure samenvatting hebben de neiging om genegeerd te
+ worden.</para>
+
+ <para>Zoals hierboven vermeld, als uw probleemrapport een
+ patch bevat, begin dan alstublieft de samenvatting met
+ <literal>[patch]</literal> (inclusief de haken); als het een
+ ports-PR is en u de port onderhoudt, overweeg dan om
+ <literal>[maintainer update]</literal> (inclusief de haken)
+ toe te voegen en de <quote>Class</quote> van uw PR op
+ <literal>maintainer-update</literal> te zetten.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>Severity:</emphasis> Eén van
+ <literal>non-critical</literal>,
+ <literal>serious</literal> of
+ <literal>critical</literal>. Overdrijf niet, bestempel uw
+ probleem niet als <literal>critical</literal> tenzij het
+ dat echt is (bijvoorbeeld gevallen van gegevenscorruptie,
+ serieuze functionele regressie ten opzichte van een vorige
+ -CURRENT) of als <literal>serious</literal> tenzij het
+ iets is dat vele gebruikers aangaat (kernelpanics of
+ bevriezingen; problemen met bepaalde
+ apparaatstuurprogramma's of systeemgereedschappen).
+ &os;-ontwikkelaars zullen niet noodzakelijk sneller aan uw
+ probleem werken als u de belangrijkheid ervan opblaast
+ aangezien er vele anderen zijn die precies hetzelfde
+ gedaan hebben — in feite schenken sommige
+ ontwikkelaars weinig aandacht aan dit veld vanwege deze
+ redenen.</para>
+
+ <note>
+ <para>Grote beveiligingsproblemen dienen
+ <emphasis>niet</emphasis> naar GNATS gestuurd te worden,
+ omdat alle GNATS-informatie publieke kennis is. Stuur
+ zulke problemen alstublieft per privé-mail naar
+ &a.security-officer;.</para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>Priority:</emphasis> Eén van
+ <literal>low</literal>, <literal>medium</literal> of
+ <literal>high</literal>. <literal>high</literal> dient te
+ worden gereserveerd voor problemen die bijna iedere
+ gebruiker van &os; aangaan en <literal>medium</literal> voor
+ iets dat vele gebruikers aangaat.</para>
+
+ <note>
+ <para>Dit veld is zo vaak misbruikt dat het bijna volledig
+ zinloos is geworden.</para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>Category:</emphasis> Kies een geschikte
+ categorie.</para>
+
+ <para>Het eerste wat u moet doen is beslissen in welk gebied
+ van het systeem uw probleem ligt. Onthoud dat &os; een
+ compleet besturingssysteem is, dat zowel een kernel, de
+ standaardbibliotheken, vele hulpstuurprogramma's, en een
+ groot aantal gereedschappen (het
+ <quote>basissysteem</quote>) installeert. Er zijn echter
+ duizenden aanvullende applicaties in de Portscollectie. U
+ dient eerst te beslissen of het probleem in het basissysteem
+ zit of dat het in iets dat via de Portscollectie
+ geïnstalleerd is zit.</para>
+
+ <para>Hier volgt een beschrijving van de grote
+ categoriën:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>Als er een probleem met de kernel, de bibliotheken
+ (zoals de standaard C-bibliotheek
+ <literal>libc</literal>), of een hulpstuurprogramma is,
+ gebruikt u in het algemeen de categorie
+ <literal>kern</literal>. (Er zijn enkele uitzonderingen
+ die hieronder vermeld staan). In het algemeen zijn dat
+ dingen die in sectie 2, 3, of 4 van de
+ handleidingpagina's staan beschreven.</para>
+ </listitem>
+
+ <listitem>
+ <para>Als er een probleem met een binair programma zoals
+ &man.sh.1; of &man.mount.8; is, dient u eerst te bepalen
+ of deze programma's deel zijn van het basissysteem of
+ dat ze via de Portscollectie zijn toegevoegd. Als u het
+ niet zeker weet, kunt u <command>whereis
+ <replaceable>programmanaam</replaceable></command>
+ uitvoeren. De conventie van &os; voor de Portscollectie
+ is om alles onder <filename
+ class="directory">/usr/local</filename> te
+ installeren, alhoewel dit door een systeembeheerder
+ veranderd kan worden. Voor dezen gebruikt u de
+ categorie <literal>ports</literal> (zelfs als de
+ categorie van de port <literal>www</literal> is; zie
+ hieronder). Als de locatie
+ <filename class="directory">/bin</filename>,
+ <filename class="directory">/usr/bin</filename>,
+ <filename class="directory">/sbin</filename>, of
+ <filename class="directory">/usr/sbin</filename> is,
+ dan is het een onderdeel van het basissysteem, en dient
+ u de categorie <literal>bin</literal> te gebruiken.
+ (Enkele programma's, zoals &man.gcc.1;, gebruiken
+ eigenlijk de categorie <literal>gnu</literal>, maar
+ daarover hoeft u zich nu geen zorgen te maken.) Dit
+ zijn allemaal programma's die in sectie 1 of 8 van de
+ handleidingpagina's worden beschreven.</para>
+ </listitem>
+
+ <listitem>
+ <para>Als u denkt dat de fout in de opstartscripts
+ <literal>(rc)</literal> zit, of in een ander type
+ onuitvoerbaar configuratiebestand, dan is de juiste
+ categorie <literal>conf</literal> (configuratie). Deze
+ dingen worden in sectie 5 van de handleidingpagina's
+ beschreven.</para>
+ </listitem>
+
+ <listitem>
+ <para>Als u een probleem in de documentatie (artikelen,
+ boeken, handleidingpagina's) heeft gevonden, dan is de
+ juiste keuze <literal>docs</literal>.</para>
+ </listitem>
+
+ <listitem>
+ <para>Als u een probleem heeft met de
+ <ulink url="&url.base;">&os; webpagina's</ulink>, dan is
+ de juiste <literal>www</literal>.</para>
+
+ <note>
+ <para>Als u problemen heeft met iets dat van een port
+ genaamd <literal>www/<replaceable>portnaam</replaceable></literal>
+ afkomt, dan hoort dit desalniettemin in de categorie
+ <literal>ports</literal> thuis.</para>
+ </note>
+ </listitem>
+ </itemizedlist>
+
+ <para>Er zijn nog enkele gespecialiseerde
+ categoriën:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>Als het probleem in <literal>kern</literal> gestopt
+ zou worden maar met het USB-subsysteem te maken heeft,
+ dan is de juiste keuze <literal>usb</literal>.</para>
+ </listitem>
+
+ <listitem>
+ <para>Als het probleem in <literal>kern</literal> gestopt
+ zou worden maar het met de threading-bibliotheken te
+ maken heeft, dan is de juiste keuze
+ <literal>threads</literal>.</para>
+ </listitem>
+
+ <listitem>
+ <para>Als het probleem in het basissysteem zit, maar het
+ met onze naleving van standaarden zoals &posix; te maken
+ heeft, dan is de juiste keuze
+ <literal>standards</literal>.</para>
+ </listitem>
+
+ <listitem>
+ <para>Als het probleem te maken heeft met interne fouten
+ van de &java.virtual.machine; (&jvm;), dan dient u de
+ categorie <literal>java</literal> te kiezen, zelfs als
+ was &java; vanuit de Portscollectie geïnstalleerd.
+ Meer algemene problemen met &java;-ports horen nog
+ steeds onder <literal>ports</literal> thuis.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>Dit laat al het andere achter.</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>Als u ervan overtuigd bent dat het probleem zich
+ alleen voordoet onder de processorarchitectuur die u
+ gebruikt, kies dan één van de
+ architectuurspecifieke categoriën: gewoonlijk
+ <literal>i386</literal> voor Intel-compatibele machines
+ in 32-bit-modus; <literal>amd64</literal> voor
+ AMD-machines die in 64-bit-modus draaien (dit omvat ook
+ Intel-compatibele machines die in EMT64-modus draaien);
+ en minder gewoonlijk <literal>arm</literal>,
+ <literal>ia64</literal>, <literal>powerpc</literal>, en
+ <literal>sparc64</literal>.</para>
+
+ <note>
+ <para>Deze categoriën worden vaak misbruikt voor
+ <quote>Ik weet het niet</quote>-problemen. Gebruik
+ alstublieft <literal>misc</literal>, in plaats van te
+ raden.</para>
+ </note>
+
+ <example>
+ <title>Correct gebruik van een arch-specifieke
+ categorie</title>
+
+ <para>U heeft een gewone PC-gebaseerde machine, en denkt
+ dat u een probleem bent tegengekomen dat specifiek is
+ voor een bepaalde chipset of een bepaald moederbord:
+ <literal>i386</literal> is de juiste categorie.</para>
+ </example>
+
+ <example>
+ <title>Onjuist gebruik van een arch-specifieke
+ categorie</title>
+
+ <para>U heeft een probleem met een insteekkaart op een
+ veelvoorkomende bus, of een probleem met een bepaald
+ type harde schijfstation: in dit geval is het
+ waarschijnlijk op meer dan één
+ architectuur van toepassing, en is
+ <literal>kern</literal> de juiste categorie.</para>
+ </example>
+ </listitem>
+
+ <listitem>
+ <para>Als u echt niet weet waar het probleem zich bevindt
+ (of als de uitleg niet bij een van de bovenstaanden
+ lijkt te passen), gebruik dan de categorie
+ <literal>misc</literal>. Voordat u dit doet, kunt u
+ eerst hulp vragen aan de &a.questions;. U krijgt dan
+ misschien het advies dat een bestaande categorie echt
+ een betere keuze is.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>Hier is een actuele lijst van categoriën (van
+ <ulink url="http://www.FreeBSD.org/cgi/cvsweb.cgi/src/gnu/usr.bin/send-pr/categories"></ulink>):</para>
+
+ <itemizedlist>
+ <listitem>
+ <para><literal>advocacy:</literal> problemen gerelateerd
+ aan het publieke imago van &os;. Overbodig.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>alpha:</literal> problemen specifiek aan
+ het platform Alpha.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>amd64:</literal> problemen specifiek aan
+ het platform AMD64.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>arm:</literal> problemen specifiek aan het
+ platform ARM.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>bin:</literal> problemen met
+ gebruikersprogramma's in het basissysteem.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>conf:</literal> problemen met
+ configuratiebestanden, standaardwaarden,
+ enzovoorts.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>docs:</literal> problemen met
+ handleidingpagina's of online documentatie.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>gnu:</literal> problemen met
+ geïmporteerde GNU-software zoals &man.gcc.1; of
+ &man.grep.1;.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>i386:</literal> problemen specifiek aan het
+ &i386;-platform.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>ia64:</literal> problemen specifiek aan het
+ ia64-platform.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>java:</literal> problemen gerelateerd aan
+ de &java; Virtual Machine.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>kern:</literal> problemen met de kernel,
+ (platforminspecifieke) apparaatstuurprogramma's, of
+ de basisbibliotheken.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>misc:</literal> alles wat niet in een van
+ de andere categoriën past. (Merk op dat er bijna
+ niets is wat echt in deze categorie past, behalve
+ problemen met de uitgave- en bouwinfrastructuur.
+ Tijdelijke bouwfouten op <literal>HEAD</literal> horen
+ hier niet thuis. Merk ook op dat dingen in deze
+ categorie gemakkelijk kwijtraken).</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>ports:</literal> problemen gerelateerd aan
+ de Portscollectie.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>powerpc:</literal> problemen specifiek voor
+ het &powerpc;-platform.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>sparc64:</literal> problemen specifiek voor
+ het &sparc64;-platform.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>standards:</literal> Zaken met betrekking
+ tot conformatie aan standaarden.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>threads:</literal> problemen gerelateerd
+ aan de implementatie van threads op &os; (in het
+ bijzonder op &os.current;).</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>usb:</literal> problemen gerelateerd aan de
+ implementatie van USB op &os;.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>www:</literal> Veranderingen of
+ verbeteringen aan de website van &os;.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>Class:</emphasis> Kies één van
+ de volgenden:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para><literal>sw-bug:</literal> softwarebugs.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>doc-bug:</literal> fouten in
+ documentatie.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>change-request:</literal> verzoeken voor
+ aanvullende mogelijkheden of veranderingen in bestaande
+ mogelijkheden.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>update:</literal> updates aan ports of
+ andere bijgedragen software.</para>
+ </listitem>
+
+ <listitem>
+ <para><literal>maintainer-update:</literal> updates aan
+ ports die u onderhoudt.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>Release:</emphasis> De versie van &os; die u
+ draait. Dit wordt automatisch ingevuld als u
+ &man.send-pr.1; gebruikt en hoeft alleen veranderd te worden
+ als u een probleemrapport verstuurt vanaf een ander systeem
+ dan van hetgene waarop het probleem zich voordoet.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>Ten slotte zijn er een aantal meerregelige velden:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para><emphasis>Environment:</emphasis> Dit dient zou
+ nauwkeurig mogelijk de omgeving te beschrijven waarin het
+ probleem is waargenomen. Dit omvat de versie van het
+ besturingssysteem, de versie van het specifieke programma of
+ bestand dat het probleem bevat, en alle andere relevante
+ zaken zoals systeemconfiguratie, andere geïnstalleerde
+ software dat het probleem beïnvloedt, enzovoorts—
+ eigenlijk alles wat een ontwikkelaar moet weten om de
+ omgeving te reconstrueren waarin het probleem
+ optreedt.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>Description:</emphasis> Een complete en
+ nauwkeurige beschrijving van het probleem dat u ondervindt.
+ Probeer speculaties over de oorzaken van het probleem te
+ vermijden tenzij u zeker weet dat u op het juiste spoor zit,
+ aangezien een ontwikkelaar hierdoor onjuiste aannames over
+ het probleem kan maken.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>How-To-Repeat:</emphasis> Een samenvatting van
+ de acties die nodig waren om het probleem te
+ reproduceren.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>Fix:</emphasis> Bij voorkeur een patch, of op
+ zijn minst een tijdelijke oplossing (wat niet alleen andere
+ mensen helpt om om het probleem heen te werken, maar
+ mogelijk ook een ontwikkelaar de oorzaak van het probleem
+ helpt te begrijpen), maar als u hier ook geen echte
+ ideëen over heeft is het beter om dit veld open te
+ laten dan om te speculeren.</para>
+ </listitem>
+ </itemizedlist>
+ </section>
+
+ <section>
+ <title>Het probleemrapport versturen</title>
+
+ <para>Als u &man.send-pr.1; gebruikt:</para>
+
+ <para>Als u klaar bent met het invullen van het sjabloon, het
+ heeft opgeslagen, en uw tekstverwerker verlaten heeft, zal
+ &man.send-pr.1; u de prompt <prompt>s)end, e)dit or
+ a)bort?</prompt> tonen. U kunt dan <userinput>s</userinput>
+ aanslaan om het probleemrapport in te sturen,
+ <userinput>e</userinput> aanslaan om de tekstverwerker te
+ herstarten en verdere wijzigingen te maken, of
+ <userinput>a</userinput> aanslaan om te stoppen. Als u het
+ laatste kiest, blijft uw probleemrapport bewaard op schijf
+ (&man.send-pr.1; vertelt u de bestandsnaam voordat het eindigt),
+ zodat u het rustig kunt bewerken, of het misschien over kunt
+ plaatsen naar een systeem met een betere netverbinding, voordat
+ u het met de optie <option>-f</option> van &man.send-pr.1;
+ verstuurt:</para>
+
+<screen>&prompt.user; <userinput>send-pr -f ~/mijn-probleemrapport</userinput></screen>
+
+ <para>Dit leest het gespecificeerde bestand, controleert de
+ geldigheid van de inhoud, verwijdert commentaar en verstuurt
+ het.</para>
+
+ <para>Als u het <ulink
+ url="&url.base;/send-pr.html">webformulier</ulink>
+ gebruikt:</para>
+
+ <para>Voordat u op <literal>submit</literal> drukt, moet u een
+ veld invullen waarin tekst staat dat als afbeelding op de pagina
+ wordt weergegeven. Deze ongelukkige maatregel moest worden
+ genomen vanwege het misbruik door geautomatiseerde systemen en
+ enkele kwaadwillige gebruikers. Het is noodzakelijk kwaad dat
+ niemand leuk vindt; vraag ons alstublieft niet om het te
+ verwijderen.</para>
+
+ <para>Merk op dat u <literal>ten zeerste wordt
+ aangeraden</literal> om uw werk ergens op te slaan voordat u
+ op <literal>submit</literal> drukt. Een veelvoorkomend probleem
+ voor gebruikers is dat hun webbrowser een verouderde afbeelding
+ uit de cache laat zien. Als u dit overkomt, wordt uw inzending
+ geweigerd en kan u uw werk verliezen.</para>
+
+ <para>Als u om een bepaalde reden geen afbeeldingen kunt bekijken,
+ en u ook &man.send-pr.1; niet kunt gebruiken, accepteer dan
+ alstublieft onze verontschuldigingen voor het ongemak en email
+ uw probleemrapport naar het bugbuster-team op
+ <email>freebsd-bugbusters@FreeBSD.org</email>.</para>
+ </section>
+ </section>
+
+ <section id="pr-followup">
+ <title>Vervolg</title>
+
+ <para>Als uw probleemrapport eenmaal is ingestuurd, ontvangt u een
+ bevestiging per email waarin het volgnummer dat aan uw
+ probleemrapport was toegewezen en een URL dat u kunt gebruiken om
+ de status te controleren zijn opgenomen. Met een beetje geluk zal
+ iemand interesse in uw probleem tonen en proberen het op te
+ lossen, of, wat het geval kan zijn, uitleggen waarom het geen
+ probleem is. U wordt automatisch op de hoogte gehouden van alle
+ toestandsveranderingen, en u ontvangt kopiën van al het
+ commentaar en patches die iemand aan het controletraject van uw
+ probleemrapport kan koppelen.</para>
+
+ <para>Als iemand aanvullende informatie van u vraagt, of als u zich
+ iets herinnert of iets ontdekt dat u niet in het initiële
+ rapport noemde, gebruik dan alstublieft één van de
+ twee methoden om uw vervolg in te sturen:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>De gemakkelijkste manier is om de vervolgkoppeling op de
+ webpagina van het individuele PR te gebruiken, welke u kunt
+ bereiken vanuit de <ulink
+ url="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query">
+ PR-zoekpagina</ulink>. Het klikken op deze koppeling brengt
+ een email-venster naar voren met daarin de juiste regels voor
+ Aan: en Onderwerp: ingevuld (als uw browser is ingesteld om
+ dit te doen).</para>
+ </listitem>
+
+ <listitem>
+ <para>Als alternatief kunt u het naar &a.bugfollowup; mailen,
+ waarbij het volgnummer in het onderwerp is opgenomen zodat het
+ foutenvolgsysteem weet aan welk probleemrapport het het moet
+ koppelen.</para>
+
+ <note>
+ <para>Als u het volgnummer <emphasis>niet</emphasis> opgeeft,
+ raakt GNATS in de war en maakt het een geheel nieuw PR aan
+ welke het vervolgens aan de GNATS-beheerder toekent, en
+ vervolgens raakt uw PR kwijt totdat iemand de rommel
+ opruimt, wat dagen of weken later kan zijn.</para>
+
+ <para>Verkeerde manier:</para>
+
+ <programlisting>Onderwerp: that PR I sent</programlisting>
+
+ <para>Juiste manier:</para>
+
+ <programlisting>Onderwerp: Re: ports/12345: compilation problem with foo/bar</programlisting>
+ </note>
+ </listitem>
+ </itemizedlist>
+
+ <para>Als het probleemrapport open blijft nadat het probleem is
+ opgelost, stuur dan een vervolg (op de bovenstaande manier) waarin
+ u vertelt dat het probleemrapport gesloten kan worden, en indien
+ mogelijk, uitlegt hoe of wanneer het probleem was opgelost.</para>
+ </section>
+
+ <section id="pr-problems">
+ <title>Als u problemen heeft</title>
+
+ <para>De meeste PR's gaan door het systeem en worden snel
+ geaccepteerd; soms loopt GNATS echter achter en kan het zijn dat u
+ uw email-bevestiging pas na 10 minuten of zelfs later ontvangt.
+ Wees alstublieft geduldig.</para>
+
+ <para>Tevens geldt, omdat GNATS alle invoer via email ontvangt, dat
+ het absoluut noodzakelijk is dat &os; alle inzendingen door
+ spam-filters haalt. Als u binnen een uur of twee geen antwoord
+ krijgt, kan uw PR misschien zijn opgeslokt; als dit zo is, neem
+ dan alstublieft contact op met de GNATS-beheerders op
+ <email>bugmeister@FreeBSD.org</email> en vraag om hulp.</para>
+
+ <note>
+ <para>Een veelvoorkomende anti-spam-maatregel is het vergelijken
+ met vele vormen van misbruik die in HTML-gebaseerde email
+ voorkomen (alhoewel niet noodzakelijk het slechts opnemen van
+ HTML in een PR). We raden het gebruik van HTML-gebaseerde email
+ voor het versturen van PR's sterk af: niet alleen is het
+ waarschijnlijker dat het niet door de filters komt, het heeft
+ ook de neiging om de database te verstoppen. Oude platte email
+ wordt sterk geprefereerd.</para>
+ </note>
+
+ <para>In zeldzame gevallen zult een bug in GNATS tegenkomen waarbij
+ een PR geaccepteerd is en een volgnummer toegewezen heeft gekregen
+ maar waarbij het niet op de lijst van PR's van een van de
+ opvraag-webpagina's staat. Het kan zijn gebeurd dat de index van
+ database niet meer met de database zelf is gesynchroniseerd. De
+ manier waarop u dit kunt testen is door de webpagina <ulink
+ url="http://www.FreeBSD.org/cgi/query-pr.cgi">bekijk een enkel
+ PR</ulink> op te roepen en te kijken of het PR wordt vermeld.
+ Als dat zo is, stel dan alstublieft de GNATS-beheerders op
+ <email>bugmeister@FreeBSD.org</email> op de hoogte. Merk op dat
+ er een <literal>cron</literal>-taak is die de database periodiek
+ herbouwt, dus u hoeft geen actie te ondernemen tenzij u haast
+ heeft.</para>
+ </section>
+
+ <section id="pr-further">
+ <title>Verdere literatuur</title>
+
+ <para>Er is een lijst met bronnen die relevant is voor het juist
+ schrijven en verwerken van probleemrapporten. Het is in geen
+ geval compleet.</para>
+
+ <itemizedlist>
+ <listitem>
+ <para><ulink
+ url="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html">
+ How to Report Bugs Effectively</ulink>—een uitstekend
+ essay door Simon G. Tatham over het samenstellen van nuttige
+ (niet-&os;-specifieke) probleemrapporten.</para>
+ </listitem>
+ <listitem>
+ <para><ulink
+ url="&url.articles.pr-guidelines;/article.html">Problem
+ Report Handling Guidelines</ulink>—waardevolle inzichten
+ in hoe probleemrapporten worden afgehandeld door de
+ &os;-ontwikkelaars.</para>
+ </listitem>
+ </itemizedlist>
+ </section>
+</article>