Bug management/Phabricator etiquette/nl

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

U moet ook de Gedragsrichtlijn volgen.

• Opmerkingen moeten direct verband houden met het rapporteren, het bevestigen, het 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 u maar hard genoeg uw 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 u 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.
   • Wees informatief – Vertel wat ze doen, wat ze niet moeten doen. Indien relevant, verwijs hen naar dit document.
   • Wees weerbaar – Vertel wat ze in plaats daarvan moeten doen. Af en toe kan dit bemoedigend en motiverend zijn, beter dan een lange lijst met "regels".
2. In het geval van aanhoudende veronachtzaming van deze richtlijnen, licht een Phabricator-beheerder in #wikimedia-releng ^verbinden op Wikimedia IRC of neem contact op met de bugwrangler en vraag hen ernaar te kijken. In het geval dat de veronachtzaming kan worden gezien als onaanvaardbaar gedrag zoals gedefinieerd in de Code of Conduct, zal de Commissie Gedragscode hiervan op de hoogte worden gesteld.

Document inspiratie

• Mozilla etiquette
• Bugzilla ː het doen en laten op het Mozilla Developer Network
• Overleg via de mailinglijst teampractices, verwijzend naar het gebruik van RESOLVED WONTFIX in Bugzilla (nu "verouderd" op Phabricator) en gerelateerde problemen

Zie ook

• Waarom heeft nog niemand dit probleem opgelost? Waarom ben ik niet geraadpleegd over deze wijzigingen? Hoe kan ik invloed uitoefenen op waar aan gewerkt wordt?
• Bug rapport levensduur
• Overeenkomsten en verschillen tussen de Bugzilla manier en de wiki manier
• Hoe een bug rapporteren
• Phabricator/Help
• Verwacht gedrag