Bug management/Phabricator etiquette/nl

Volg deze richtlijnen om ervoor te zorgen dat een productieve en collaboratieve omgeving is voor het beheren van bugrapporten en functieverzoeken.

U moet ook de volgen.


 * Opmerkingen moeten direct verband houden met rapportage, het bevestigen, evalueren van de ernst of het oplossen van de bug. Teksten die geen verband houden met het onderwerp van het rapport (bijvoorbeeld discussies op metaniveau over prioriteiten in het algemeen of over de vraag of een nieuwe extensie überhaupt gewenst is) moeten via de geschikte mailinglijsten, wiki-overlegpagina's of afzonderlijke rapporten gaan.
 * Hou het zakelijk, het gaat om de ideeën en niet om de personen. Opbouwende kritiek en een levendig debat helpt om onze software te verbeteren, dat wordt dus aangemoedigd.
 * Doe alles onder uw naam, geef dus geen anonieme kritiek. Tenzij u een beveiligingsprobleem meldt of u werd gevraagd iemand een e-mail te sturen met specifieke informatie, plaatst u alle technische informatie met betrekking tot een bug in het rapport zelf.
 * Rapportstatus en prioriteitsvelden vatten samen en weerspiegelen realiteit maar veroorzaken het niet Lees over de betekenis van de prioriteitsveldwaarden, wijzig ze bij twijfel niet, voeg een opmerking toe die de wijziging aangeeft met overtuigende redenen daarvoor.
 * Als algemene regel geldt dat de snelste manier om een bug opgelost te zien, is het door een een patch aan te leveren (zie ook Prioritering van ontwikkeling).
 * Overtuigende redenen voor het verhogen van de prioriteit van een bug zijn onder meer bewijs dat het het normale, dagelijkse werk aanzienlijk beïnvloedt. Gekunstelde voorbeelden of problemen die alleen onder onwaarschijnlijke omstandigheden verschijnen, zijn over het algemeen bewijs voor het behandelen van het probleem als "lage" prioriteit, omdat de grenzen van niet-triviale software kunnen worden overschreden als je maar hard genoeg je best doet.
 * Plaats geen opmerkingen als "Los dit nu op".
 * Wijs een taak alleen handmatig aan iemand toe als diegene vooraf toestemming heeft gegeven. Het is aan ontwikkelaars (of hun productmanagers) waar ze aan willen werken.
 * Geef de voorkeur aan het gebruik van Phabricator-gebruikersnamen (bijv. @username) boven de echte naam van een persoon of andere persoonlijke gegevens. Om zowel zorgen over privacy als onnodige verwarring aan te pakken, gebruikt u bij het communiceren over verschillende taken, phame-berichten, enz., de Phabricator-gebruikersnamen. Zelfs als u personen op persoonlijk niveau kent (echte naam, enz.), willen ze misschien niet dat die informatie is gekoppeld aan hun Phabricator-gebruikersnaam. Het geeft ook verwarring bij andere Phabricator-gebruikers die zich niet bewust zijn van iemands echte naam of andere persoonlijke gegevens.

Als je ziet dat iemand deze richtlijnen niet volgt of niet opbouwend bezig is:


 * 1) De eerste stap is om contact met hen op te nemen. Dit kan worden gedaan via privé e-mail bij kleinere zaken of in het openbaar bij ernstige zaken latere aannames van getolereerd gedrag te voorkomen.
 * 2) * Wees informatief – Vertel wat ze doen, wat ze niet moeten doen. Indien relevant, verwijs hen naar dit document.
 * 3) * Wees weerbaar – Vertel wat ze in plaats daarvan moeten doen. Occasionally this may be encouraging and motivating, better than a dense list of "rules".
 * 4) In the case of persistent disregard of these guidelines, ping a Phabricator administrator in  on Wikimedia IRC or contact the bugwrangler and ask them to look into it. In case the disregard can be seen as unacceptable behavior defined by the Code of Conduct, the Code of Conduct committee will be informed.

Document inspiration

 * Mozilla etiquette
 * Bugzilla dos and don'ts at Mozilla Developer Network
 * Conversation on teampractices mailing list, referring to the use of RESOLVED WONTFIX in Bugzilla (now "declined" in Phabricator) and related problems