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 au 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 des rapports séparés.
 * Discutez des idées et non des personnes. Un apport sain de critiques constructives et un débat vivant aident souvent à améliorer notre logiciel et sont encouragés.
 * Agissez en public. Sauf si vous rapportez un problème de sécurité ou si on vous a demandé d'envoyer par courriel des informations spécifiques, mettez toutes les informations techniques relatives au rapport de bogue, dans le rapport lui-même.
 * Les champs Etat du rapport et Priorité résument et traduisent la réalité mais ne la provoquent pas. Lisez la signification des valeurs du champ Priorité et, si vous avez un doute ne le modifiez pas mais ajoutez un commentaire suggérant sa modification avec des motifs convaincants en ce sens.
 * En règle générale, la manière la plus rapide de voir qu'un bogue est corrigé,est de fournir un patch (voir aussi les priorités dans le développement).
 * Les raisons majeures pour augmenter la priorité d'un bogue comprennent l'évidence qu'il affecte le travail quotidien de manière significative. Les exemples artificiels ou les problèmes qui n'apparaissent que dans des circonstances improbables vont évidemment être classés avec une priorité basse, voire la plus basse, car vous pourrez toujours dépasser les limites d'un système non évident, pour peu que vous insistiez suffisamment.
 * Assignez manuellement une tâche à quelqu'un uniquement s'il a donné son accord avant. Il appartient aux développeurs eux-mêmes (ou à leur gestionnaire de produit) de définir sur quoi ils vont travailler.
 * Préférez l'usage du nom d'utilisateur de Phabricator (par exemple @username) plutôt que le vrai nom de la personne ou d'autres identifiants personnels. Pour résoudre à la fois les problèmes concernant la confidentialité et la confusion inutile, lorsque vous communiquez sur des tâches différentes, des collages, des billets, etc, veuillez utiliser les noms utilisateur de Phabricator. Même si vous connaissez les gens d'un point de vue personnel (nom réel, etc.) il est possible qu'ils ne veuillent pas voir ces informations associées à leur nom d'utilisateur dans Phabricator. Cela présente également un niveau de confusion pour les autres utilisateurs de Phabricator qui ne sont pas conscients du vrai nom de la personne ni de ses autres identifiants personnels.

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 à sa connaissance.
 * 3) * Soyez catalyseur – Dites à la place ce qu'il faudrait faire. Quelques fois ceci peut être plus encourageant et motivant, meilleur qu'une liste dense de règles.
 * 4) Si ces règles continuent d'être ignorées, faites un ping sur un administrateur Phabricator de  sur Wikimedia IRC ou contactez le  bugwrangler et demandez-lui de regarder le problème. Dans le cas où le contrevenant aurait un comportement inacceptable parmi ceux définis dans le Code de conduite, le Comité du code de conduite en sera informé.



Inspiration pour la documentation

 * L'Etiquette Mozilla
 * Ce que fait Bugzilla et ce qu'il ne fait pas sur le réseau des développeurs Mozilla
 * Conversation à propos de la liste de diffusion des pratiques de l'équipe, relativement à l'utilisation de RESOLVED WONTFIX dans Bugzilla ("refusée" maintenant dans Phabricator) et problèmes associés



Voir aussi

 * Pourquoi personne n'a pas encore corrigé ce problème ? Pourquoi n'ai-je pas été consulté à propos de ces modifications ? Comment puis-je agir sur le travail actuellement en cours ?
 * Cycle de vie d'un rapport de bogue
 * Similarités et différences entre la manière Bugzilla et la manière wiki
 * Solutions disponibles pour les utilisateurs qui sont en désaccord avec les décisions techniques de la Fondation Wikimedia
 * Comportement attendu
 * Comportement attendu
 * Comportement attendu