Skip to content

Commit

Permalink
Merge pull request #3085 from omahs/patch-1
Browse files Browse the repository at this point in the history
Fix: French typos
  • Loading branch information
zkoppert committed Sep 27, 2023
2 parents 13f44c4 + 10e5224 commit d787e57
Show file tree
Hide file tree
Showing 8 changed files with 34 additions and 34 deletions.
18 changes: 9 additions & 9 deletions _articles/fr/best-practices.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@ Rédaction des choses rend plus facile de dire non quand quelque chose ne rentre

Même si vous n'utilisez pas de paragraphes entiers, des listes de point sont mieux que de ne pas écrire du tout.

N'oubliez pas de garder votre documentation à jour. Si vous n'êtes pas toujours en mesure le faire, supprimez votre documentation obsolète ou indiquez qu'elle est obsolète afin que les contributeurs sachent que les mises à jour sont les bienvenues.
N'oubliez pas de garder votre documentation à jour. Si vous n'êtes pas toujours en mesure de le faire, supprimez votre documentation obsolète ou indiquez qu'elle est obsolète afin que les contributeurs sachent que les mises à jour sont les bienvenues.

### Décrivez la vision de votre projet

Expand Down Expand Up @@ -87,7 +87,7 @@ Dire non s'applique à de nombreuses situations que vous rencontrerez en tant qu

### Gardez la conversation amicale

L'un des endroits les plus importants que vous pratiquez en disant non est sur votre isue et la file d'attente des pull requests. En tant que responsable du projet, vous recevrez inévitablement des suggestions que vous ne souhaitez pas accepter.
Les endroits les plus importants où pratiquer l'art du refus sont vos issues et la file d'attente des pull requests. En tant que responsable du projet, vous recevrez inévitablement des suggestions que vous ne souhaitez pas accepter.

Peut-être que la contribution modifie la portée de votre projet ou ne correspond pas à votre vision. Peut-être que l'idée est bonne, mais la mise en œuvre est mauvaise.

Expand Down Expand Up @@ -128,7 +128,7 @@ Ne vous sentez pas coupable de ne pas vouloir accepter la contribution de quelqu

En fin de compte, si une contribution n'est pas suffisante, vous n'êtes pas obligé de l'accepter. Soyez gentil et réactif lorsque les gens contribuent à votre projet, mais n'acceptez que les changements qui, selon vous, amélioreront votre projet. Le plus souvent vous pratiquez en disant non, plus cela devient facile. Promis.

### Soyez pro-actif
### Soyez proactif

Pour réduire le volume des contributions non désirées, expliquez le processus de soumission et d'acceptation des contributions de votre projet dans votre guide.

Expand All @@ -137,7 +137,7 @@ Si vous recevez trop de contributions de faible qualité, demandez aux contribut
* Remplir une issue ou un modèle de PR / checklist
* Ouvrir une issue avant de soumettre une PR

S'ils ne respectent pas vos règles, fermez immédiatement l'issue et référez a votre documentation.
S'ils ne respectent pas vos règles, fermez immédiatement l'issue et référez à votre documentation.

Bien que cette approche puisse sembler méchante au début, être proactif est réellement bon pour les deux parties. Cela réduit le risque que quelqu'un consacre beaucoup d'heures de travail perdues à une pull request que vous n'allez pas accepter. Et cela rend votre charge de travail plus facile à gérer.

Expand All @@ -155,7 +155,7 @@ Parfois, quand vous dites non, votre contributeur potentiel peut se fâcher ou c

Peut-être que quelqu'un dans votre communauté soumet régulièrement des contributions qui ne répondent pas aux normes de votre projet. Il peut être frustrant pour les deux parties de passer à plusieurs reprises par des rejets.

Si vous voyez que quelqu'un est enthousiaste à propos de votre projet, mais qu'il a besoin d'un peu de polish, soyez patient. Expliquer clairement dans chaque situation pourquoi les contributions ne répondent pas aux attentes du projet. Essayez de le diriger vers une tâche plus facile ou moins ambiguë, comme une question marquée _"bonne premiere issue"_, pour se faire les pieds. Si vous avez le temps, envisagez de l'encadrer à travers sa première contribution, ou de trouver quelqu'un d'autre dans votre communauté qui pourrait être disposé à le faire.
Si vous voyez que quelqu'un est enthousiaste à propos de votre projet, mais qu'il a besoin d'un peu de polish, soyez patient. Expliquer clairement dans chaque situation pourquoi les contributions ne répondent pas aux attentes du projet. Essayez de le diriger vers une tâche plus facile ou moins ambiguë, comme une question marquée _"bonne première issue"_, pour se faire les pieds. Si vous avez le temps, envisagez de l'encadrer à travers sa première contribution, ou de trouver quelqu'un d'autre dans votre communauté qui pourrait être disposé à le faire.

## Tirez parti de votre communauté

Expand Down Expand Up @@ -193,7 +193,7 @@ Forker un projet ne doit pas être une mauvaise chose. Etre capable de copier et

<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/geerlingguy?s=180" class="pquote-avatar" alt="avatar">
Je réponds a 80% des cas d'utilisation. Si vous êtes l'une des licornes, s'il vous plaît forker mon travail. Je ne serai pas offensé ! Mes projets publics sont presque toujours destinés à résoudre les problèmes les plus courants. J'essaie de faire en sorte qu'il soit plus facile d'approfondir mon travail ou de le prolonger.
Je réponds à 80% des cas d'utilisation. Si vous êtes l'une des licornes, s'il vous plaît forker mon travail. Je ne serai pas offensé ! Mes projets publics sont presque toujours destinés à résoudre les problèmes les plus courants. J'essaie de faire en sorte qu'il soit plus facile d'approfondir mon travail ou de le prolonger.
<p markdown="1" class="pquote-credit">
@geerlingguy, ["Why I Close PRs"](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes)
</p>
Expand All @@ -213,7 +213,7 @@ L'un des moyens les plus importants pour automatiser votre projet consiste à aj

Les tests aident les contributeurs à croire qu'ils ne casseront rien. Ils facilitent également la consultation et l'acceptation des contributions rapidement. Plus vous êtes réactif, plus votre communauté peut être engagée.

Configurez des tests automatiques qui s'exécuteront sur toutes les contributions entrantes, et assurez-vous que vos tests peuvent être facilement exécutés localement par les contributeurs. Exiger que toutes les contributions de code passent vos tests avant de pouvoir être soumis. Vous aiderez à définir une norme de qualité minimale pour toutes les soumissions. La [vérifications du status requis](https://help.github.com/articles/about-required-status-checks/) sur GitHub peut vous aider à vous assurer qu'aucune modification ne sera mergée sans que vos tests ne passent.
Configurez des tests automatiques qui s'exécuteront sur toutes les contributions entrantes, et assurez-vous que vos tests peuvent être facilement exécutés localement par les contributeurs. Exiger que toutes les contributions de code passent vos tests avant de pouvoir être soumis. Vous aiderez à définir une norme de qualité minimale pour toutes les soumissions. La [vérification du status requis](https://help.github.com/articles/about-required-status-checks/) sur GitHub peut vous aider à vous assurer qu'aucune modification ne sera mergée sans que vos tests ne passent.

Si vous ajoutez des tests, assurez-vous d'expliquer comment ils fonctionnent dans votre fichier CONTRIBUTING.

Expand All @@ -227,7 +227,7 @@ Si vous ajoutez des tests, assurez-vous d'expliquer comment ils fonctionnent dan

### Utiliser des outils pour automatiser les tâches de maintenance de base

Les bonnes nouvelles à propos du maintien d'un projet populaire sont que d'autres responsables ont probablement deja fait face à des problèmes similaires et ont construit une solution pour cela.
Les bonnes nouvelles à propos du maintien d'un projet populaire sont que d'autres responsables ont probablement déjà fait face à des problèmes similaires et ont construit une solution pour cela.

Il y a une [variété d'outils disponibles](https://github.com/showcases/tools-for-open-source) pour aider à automatiser certains aspects du travail de maintenance. Quelques exemples:

Expand Down Expand Up @@ -271,6 +271,6 @@ Faites de votre mieux pour trouver du support pour vos utilisateurs et votre com

Prendre des pauses s'applique à plus que de simples vacances, aussi. Si vous ne voulez pas faire du travail open source le week-end, ou pendant les heures de travail, communiquez ces attentes aux autres, afin qu'ils sachent ne pas vous déranger.

## Prennez soin de vous d'abord !
## Prenez soin de vous d'abord !

Maintenir un projet populaire nécessite des compétences différentes des étapes précédentes de la croissance, mais ce n'est pas moins gratifiant. En tant que responsable, vous pratiquerez le leadership et les compétences personnelles à un niveau que peu de gens connaissent. Bien que ce ne soit pas toujours facile à gérer, définir des limites claires et ne prendre que ce que vous êtes à l'aise vous aidera à rester heureux, frais et productif.
16 changes: 8 additions & 8 deletions _articles/fr/building-community.md
Original file line number Diff line number Diff line change
Expand Up @@ -29,10 +29,10 @@ Commencez avec votre documentation:
* **Facilitez l'utilisation de votre projet par quelqu'un.** [Un fichier README amical](../starting-a-project/#ecrire-un-fichier-readme) et des exemples de code clair faciliteront la tâche à tous ceux qui atterriront votre projet pour commencer.
* **Expliquez clairement comment contribuer**, en utilisant [votre fichier CONTRIBUTING](../starting-a-project/#r&eacute;daction-de-vos-directives-de-contribution) et en gardant vos issues à jour.

[L'enquête open source 2017 de GitHub](http://opensourcesurvey.org/2017/) a montrée que la documentation incomplète ou confuse est le plus gros problème pour les utilisateurs open source. Une bonne documentation invite les gens à interagir avec votre projet. Finalement, quelqu'un va ouvrir une issue ou faire une pull request. Utilisez ces interactions comme des opportunités pour les déplacer dans l'entonnoir.
[L'enquête open source 2017 de GitHub](http://opensourcesurvey.org/2017/) a montré que la documentation incomplète ou confuse est le plus gros problème pour les utilisateurs open source. Une bonne documentation invite les gens à interagir avec votre projet. Finalement, quelqu'un va ouvrir une issue ou faire une pull request. Utilisez ces interactions comme des opportunités pour les déplacer dans l'entonnoir.

* **Quand quelqu'un arrive sur votre projet, remerciez-le de son intérêt !** Il suffit d'une expérience négative pour que quelqu'un ne veuille pas revenir.
* **Soyez réactif.** Si vous ne répondez pas à leur problème pendant un mois, les chances sont, ils ont déjà oublié votre projet.
* **Soyez réactif.** Si vous ne répondez pas à leur problème pendant un mois, il est probable qu'ils aient déjà oublié votre projet.
* **Soyez ouvert sur les types de contributions que vous accepterez.** De nombreux contributeurs commencent par un rapport de bug ou une petite correction. Il y a [plusieurs façons de contribuer](../how-to-contribute/#que-signifie-contribuer) à un projet. Laissez les gens aider comment ils veulent aider.
* **S'il y a une contribution avec laquelle vous n'êtes pas d'accord,** remerciez-les pour leur idée et [expliquez pourquoi](../best-practices/#apprendre-&agrave;-dire-non) cela ne rentre pas dans le cadre de la projet, en reliant à la documentation pertinente si vous l'avez.

Expand Down Expand Up @@ -70,7 +70,7 @@ Si vous remarquez que plusieurs utilisateurs rencontrent le même problème, doc

Pour les réunions, pensez à publier vos notes ou vos plats à emporter dans un numéro pertinent. Les commentaires que vous obtiendrez de ce niveau de transparence pourraient vous surprendre.

Documenter tout s'applique au travail que vous faites aussi. Si vous travaillez sur une mise à jour substantielle de votre projet, placez-la dans une pull request et marquez-la comme un travail en cours (WIP). De cette façon, d'autres personnes peuvent se sentir impliqués dans le processus dès le début.
Documenter tout s'applique au travail que vous faites aussi. Si vous travaillez sur une mise à jour substantielle de votre projet, placez-la dans une pull request et marquez-la comme un travail en cours (WIP). De cette façon, d'autres personnes peuvent se sentir impliquées dans le processus dès le début.

### Soyez réactif

Expand All @@ -82,7 +82,7 @@ Même si vous ne pouvez pas examiner la demande immédiatement, le reconnaître

![la pull request Middleman](/assets/images/building-community/middleman_pr.png)

[Une étude de Mozilla a trouvé que](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) les contributeurs qui ont reçu des avis de code dans les 48 heures avaient un taux de rendement beaucoup plus élevé et recommencaient a contriber.
[Une étude de Mozilla a trouvé que](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) les contributeurs qui ont reçu des avis de code dans les 48 heures avaient un taux de rendement beaucoup plus élevé et recommençaient a contribuer.

Des conversations sur votre projet pourraient également avoir lieu dans d'autres endroits sur Internet, tels que Stack Overflow, Twitter ou Reddit. Vous pouvez configurer des notifications dans certains de ces endroits afin d'être averti lorsque quelqu'un mentionne votre projet.

Expand All @@ -106,15 +106,15 @@ Les exceptions notables à la communication publique sont: 1) les problèmes de

Les communautés sont extrêmement puissantes. Ce pouvoir peut être une bénédiction ou une malédiction, selon la façon dont vous l'utilisez. Au fur et à mesure que la communauté de votre projet grandit, il existe des moyens de l'aider à devenir une force de construction, pas de destruction.

### Ne tol&egrave;rez pas les mauvais acteurs
### Ne tolérez pas les mauvais acteurs

Tout projet populaire attirera inévitablement des gens qui nuisent à votre communauté plutôt que de l'aider. Ils peuvent lancer des débats inutiles, ergoter sur des fonctionnalités triviales, ou intimider les autres.

Faites de votre mieux pour adopter une politique de tolérance zéro envers ces types de personnes. Si rien n'est fait, les personnes négatives mettront mal à l'aise les autres membres de votre communauté. Ils peuvent même partir.

<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/okdistribute?s=180" class="pquote-avatar" alt="avatar">
La vérité est qu'ayant une communauté de soutien est la clé. Je ne serais jamais capable de faire ce travail sans l'aide de mes collègues, des étrangers sympathiques sur Internet, et des canaux IRC bavards. (...) Ne vous contentez pas de moins. Ne vous contentez pas de connards.
La vérité est qu'avoir une communauté de soutien est la clé. Je ne serais jamais capable de faire ce travail sans l'aide de mes collègues, des étrangers sympathiques sur Internet, et des canaux IRC bavards. (...) Ne vous contentez pas de moins. Ne vous contentez pas de connards.
<p markdown="1" class="pquote-credit">
@okdistribute, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)
</p>
Expand Down Expand Up @@ -192,7 +192,7 @@ Pour la plupart, si vous avez cultivé une communauté amicale et respectueuse e

Lorsque votre communauté est aux prises avec un problème difficile, la colère peut monter. Les gens peuvent devenir fâchés ou frustrés et s'en prendre à un autre ou à vous.

Votre travail en tant que mainteneur consiste à éviter l'escalade de ces situations. Même si vous avez une opinion forte sur le sujet, essayez de prendre la position d'un modérateur ou d'un facilitateur, plutôt que de vous jeter dans la bagarre et de faire valoir vos points de vue. Si quelqu'un est méchant ou accapare la conversation, [agissez immédiatement](../building-community/#ne-tol&egrave;rez-pas-les-mauvais-acteurs) pour garder les discussions civiles et productives.
Votre travail en tant que mainteneur consiste à éviter l'escalade de ces situations. Même si vous avez une opinion forte sur le sujet, essayez de prendre la position d'un modérateur ou d'un facilitateur, plutôt que de vous jeter dans la bagarre et de faire valoir vos points de vue. Si quelqu'un est méchant ou accapare la conversation, [agissez immédiatement](../building-community/#ne-tolérez-pas-les-mauvais-acteurs) pour garder les discussions civiles et productives.

<aside markdown="1" class="pquote">
<img src="https://avatars.githubusercontent.com/kennethreitz?s=180" class="pquote-avatar" alt="avatar">
Expand Down Expand Up @@ -230,7 +230,7 @@ Dans le cadre d'un processus de recherche de consensus, les membres de la commun

Même si vous n'adoptez pas un processus de recherche de consensus, en tant que responsable de projet, il est important que les gens sachent que vous écoutez. Faire en sorte que les autres se sentent entendus, et s'engager à résoudre leurs problèmes, contribue grandement à la diffusion des situations sensibles. Ensuite, suivez vos mots avec des actions.

Ne vous précipitez pas dans une décision pour avoir une résolution. Assurez-vous que tout le monde se sent entendu et que toutes les informations ont été rendues publiques avant de passer à une résolution.
Ne vous précipitez pas dans une décision pour avoir une résolution. Assurez-vous que tout le monde se sente entendu et que toutes les informations ont été rendues publiques avant de passer à une résolution.

### Maintenir la conversation centrée sur l'action

Expand Down
Loading

0 comments on commit d787e57

Please sign in to comment.