Bug management/Phabricator etiquette/fr

Veuillez suivre ces règles pour que reste un environnement de production collaboratif pour la gestion des rapports de bogues et des demandes de fonctionnalités.

Vous devez également suivre le.


 * Les commentaires doivent être directement liés avec le rapport, la confirmation, l'évaluation de la gravité, ou la correction du bogue. Les idées qui n'ont rien à voir avec le sujet du rapport (par exemple, les discussions de méta-niveau sur les priorités en général, ou si une nouvelle extension est absolument demandée) doivent aller dans la liste de diffusion appropriée, les pages de discussion du wiki, ou dans les rapports séparés.
 * Criticize ideas, not people. 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 summarize 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 prioritization).
 * 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" or "lowest" priority, since the limits of any non-trivial software can be exceeded if you try hard enough.
 * 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.

Si vous vous apercevez que quelqu'un ne suit pas ces règles ou n'est pas productif :


 * 1) La première étape est de le contacter. Dans les rares cas, cela peut être fait par un mail privé, ou en public dans la majorité des cas, pour éviter des suppositions ultérieures de comportement toléré.
 * 2) * Apportez de l'information – Dites ce qui est fait et ce qui ne doit pas l'être. Si cela persiste, portez ce document à la connaissance.
 * 3) * Soyez un catalyseur – Tell what they should do instead. 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.



Inspiration pour la documentation

 * Bugzilla@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



Voir aussi

 * Why has nobody fixed this issue yet? Why wasn't I consulted about these changes? How I can influence what is worked on?
 * Bug management/Bug report life cycle
 * Similarities and differences between the Bugzilla way and the wiki way
 * Remedies available to users who disagree with Wikimedia Foundation technical decisions
 * How to report a bug
 * Phabricator/Help
 * Expected behavior