Bug-Management/Phabricator-Etiquette
Outdated translations are marked like this.
Bitte halte dich an den Richtlinien, um sicher zu stellen, dass Special:MyLanguage/Phabricator eine produktive und kollaborative Umgebung für Bug-Meldungen und Funktionsanfragen bleibt.
Du must auch die Special:MyLanguage/Code of Conduct befolgen.
- Kommentare sollten direkt mit den Melden, Bestätigen, Auswertung der Sicherheit oder der Behebung des Bugs verbunden sein. Gedanken, die nicht zum Thema der Meldung relevant sind (zum Beispiel Diskussionen auf Metaebene für generelle Prioritäten oder ob überhaupt eine neue Erweiterung gewünscht wird) sollte an die angemessenen Mailinglisten, auf Wiki-Diskussionseiten oder in separaten Meldungen weitergeleitet werden.
- Kritisiere Ideen, nicht Menschen.[1] A healthy amount of constructive criticism and vibrant debate helps to improve our software and is encouraged.
- Act in public. Unless you are reporting a security issue or you were asked to email somebody with specific information, place all technical information relating to a bug report in the report itself.
- Report status and priority fields summarise and reflect reality and do not cause it. Read about the meaning of the Priority field values and, when in doubt, do not change them, but add a comment suggesting the change and convincing reasons for it.
- As a general rule, the fastest way to see a bug resolved is to provide a patch (see also Development prioritisation).
- Convincing reasons for raising the priority of a bug include evidence that it affects normal, everyday work significantly. Contrived examples or problems that only appear under unlikely circumstances are generally evidence for treating the problem as "low" priority, since the limits of any non-trivial software can be exceeded if you try hard enough.
- Do not post votes or comments like "Fix this now".
- Only manually assign a task to someone if they have given their prior agreement. It is up to developers (or their product managers) what they plan to work on.
- Prefer using Phabricator usernames (e.g. @username) over a person's real name or other personal identifiers. To address both concerns regarding privacy and unnecessary confusion, when communicating on various tasks, pastes, phame posts, etc, please use Phabricator usernames. Even if you know individuals on a personal level (real name, etc.) they may not wish to have that information associated with their Phabricator username. It also presents a layer of confusion for other Phabricator users who are not aware of someone's real name or other personal identifiers.
Falls du jemanden siehst, die die Richtlinien nicht folgen oder nicht produktiv sind:
- Als Erstes solltest du die Person kontaktieren. Dies kann entweder per einer privaten E-Mail in unerheblichen Fällen passieren, oder öffentlich bei erheblichen Fällen, um später jegliche Annahmen von tolerierten Benehmen zu vermeiden.
- Sei Informativ – Sage ihn/ihr, was er/sie macht, was er/sie nicht machen soll. Falls angemessen, mach ihn/ihr aufmerksam auf dieses Dokument.
- Sei Katalytisch – Tell what they should do instead. Occasionally this may be encouraging and motivating, better than a dense list of "rules".
- In the case of persistent disregard of these guidelines, ping a Phabricator administrator in #wikimedia-releng connect on Wikimedia IRC or contact the bugwrangler and ask them to look into it. In case the disregard can be seen as unacceptable behaviour defined by the Code of Conduct, the Code of Conduct committee will be informed.
Inspriation des Dokuments
- 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
Siehe auch
- Why has nobody fixed this issue yet? Why wasn't I consulted about these changes? How can I influence what is worked on?
- Bug report life cycle
- Similarities and differences between the Bugzilla way and the wiki way
- Wie man einen Bug meldet
- Phabricator/Hilfe
- Expected behaviour
Einzelnachweise
- ↑ Failure is Always An Option: How a Blameless Culture Leads to Better Results, Jessica Kahn, September 08, 2016