diff --git a/_articles/pt/best-practices.md b/_articles/pt/best-practices.md
index 358dd493c83..15644631dae 100644
--- a/_articles/pt/best-practices.md
+++ b/_articles/pt/best-practices.md
@@ -34,7 +34,7 @@ Lembre-se de manter a sua documentação atualizada. Se você não está dispon
 
 Inicie escrevendo os objetivos do seu projeto. Adicione eles ao README, ou crie um arquivo separado chamado VISÃO. Caso existam outros artefatos que possam ajudar, como o roadmap do projeto, torne-os públicos também.
 
-Ter uma visão clara e documentada mantém você focado e ajuda a evitar a “fuga de escopo” das contribuições de outras pessoas.
+Ter uma visão clara e documentada mantém você focado e ajuda a evitar a "fuga de escopo" das contribuições de outras pessoas.
 
 Por exemplo, @lord descobriu que ter uma visão de projeto o ajudou a definir em quais requests gastaria seu tempo. Como um novo mantenedor, ele se arrependeu de não ter seguido o escopo quando recebeu sua primeira request para o [Slate](https://github.com/lord/slate).
 
@@ -69,7 +69,7 @@ Aqui estão algumas regras que valem a pena escrever:
 
 ### Mantenha a comunicação pública
 
-Não se esqueça de documentar suas interações também. Onde você puder, mantenha a comunicação sobre seu projeto pública. Se alguém tentar contatar você privativamente para discutir uma *feature request* ou um suporte necessitado, dirija ela ao canal de comunicação público, como uma lista de e-mail ou um *issue tracker*.
+Não se esqueça de documentar suas interações também. Onde você puder, mantenha a comunicação sobre seu projeto pública. Se alguém tentar contatar você privativamente para discutir uma feature request ou um suporte necessitado, dirija ela ao canal de comunicação público, como uma lista de e-mail ou um issue tracker.
 
 Se você encontrar outros mantenedores, ou tomar uma importante decisão em particular, documente essas conversas em público, mesmo que sejam apenas suas anotações.
 
@@ -87,7 +87,7 @@ Como mantenedor, você irá se deparar com diversas situações em que terá que
 
 ### Mantenha o diálogo amigável
 
-Um dos mais importantes lugares em que você irá praticar dizer não é em suas filas de *issues* e *pull requests*. Como um mantenedor de projeto, você irá inevitavelmente receber sugestões que não deseja aceitar.
+Um dos mais importantes lugares em que você irá praticar dizer não é em suas filas de issues e pull requests. Como um mantenedor de projeto, você irá inevitavelmente receber sugestões que não deseja aceitar.
 
 Talvez uma contribuição mude o escopo do projeto ou não corresponde à sua visão. Talvez a ideia seja boa, porém a implementação seja pobre.
 
@@ -97,15 +97,15 @@ Se você recebe uma contribuição que não deseja aceitar, sua primeira reaçã
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
-  A chave para assegurar o suporte em projetos *open-source* de larga escala é manter as *issues* em andamento. Tentar evitar que as *issues* estagnem. Se você é um desenvolvedor iOS, sabe o quanto é frustrante submeter radares. Você pode obter um feedback 2 anos depois dizendo para realizar uma nova solicitação com a versão mais recente do iOS.
+  A chave para assegurar o suporte em projetos open-source de larga escala é manter as issues em andamento. Tentar evitar que as issues estagnem. Se você é um desenvolvedor iOS, sabe o quanto é frustrante submeter radares. Você pode obter um feedback 2 anos depois dizendo para realizar uma nova solicitação com a versão mais recente do iOS.
   <p markdown="1" class="pquote-credit">
 — @KrauseFx, ["Escalando comunidades de código aberto"](https://krausefx.com/blog/scaling-open-source-communities)
   </p>
 </aside>
 
-Não deixe uma contribuição indesejada aberta porque você se sente culpado ou quer ser legal. Com o passar do tempo, suas *issues* e PRs não respondidas farão o trabalho em seu projeto pareça mais estressante e intimidador.
+Não deixe uma contribuição indesejada aberta porque você se sente culpado ou quer ser legal. Com o passar do tempo, suas issues e PRs não respondidas farão o trabalho em seu projeto pareça mais estressante e intimidador.
 
-É melhor fechar imediatamente as contribuições que você sabe que não deseja aprovar. Se seu projeto já sofre com um grande *backlog*, @steveklabnik tem sugestões para [como realizar a triagem de issues eficientemente](http://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+É melhor fechar imediatamente as contribuições que você sabe que não deseja aprovar. Se seu projeto já sofre com um grande backlog, @steveklabnik tem sugestões para [como realizar a triagem de issues eficientemente](http://words.steveklabnik.com/how-to-be-an-open-source-gardener).
 
 Em segundo lugar, ignorar contribuições envia um sinal negativo para sua comunidade. Contribuir para um projeto pode ser intimidador, especialmente se é a primeira vez de alguém. Mesmo que você não aceite a contribuição dele(a), dê reconhecimento à pessoa por trás dela e agradeça pelo interesse. É um grande elogio!
 
@@ -122,9 +122,9 @@ Você não precisará de mais de 1-2 sentenças para responder. Por exemplo, qua
 
 Se pensar em dizer "não" aterroriza você, você não está sozinho. Como @jessfraz relata
 
-> Eu conversei com mantenedores de vários projetos de código aberto diferentes, Mesos, Kubernetes, Chromium, e todos concordam que uma das partes mais difíceis de ser um mantenedor é dizer "Não" aos *patches* que você não quer.
+> Eu conversei com mantenedores de vários projetos de código aberto diferentes, Mesos, Kubernetes, Chromium, e todos concordam que uma das partes mais difíceis de ser um mantenedor é dizer "Não" aos patches que você não quer.
 
-Não se sinta envergonhado em não querer aceitar a contribuição de alguém. A primeira regra do *open source* [de acordo com](https://twitter.com/solomonstre/status/715277134978113536) @shykes é: _"*Não* é temporário, sim é para sempre."_ Embora a empatia com o entusiasmo de outra pessoa seja uma coisa boa, rejeitar uma contribuição não é o mesmo que rejeitar a pessoa por trás dela.
+Não se sinta envergonhado em não querer aceitar a contribuição de alguém. A primeira regra do open source [de acordo com](https://twitter.com/solomonstre/status/715277134978113536) @shykes é: _"Não é temporário, sim é para sempre."_ Embora a empatia com o entusiasmo de outra pessoa seja uma coisa boa, rejeitar uma contribuição não é o mesmo que rejeitar a pessoa por trás dela.
 
 Por fim, se uma contribuição não é boa o suficiente, você não possui a obrigação de aceitá-la. Seja gentil e responsivo quando as pessoas contribuírem com seu projeto, porém aceite somente mudanças que você realmente acredita que tornarão seu projeto melhor. Quanto mais você pratica dizer não, mais fácil se torna. Juro.
 
@@ -134,12 +134,12 @@ Para reduzir a quantidade de contribuições indesejadas, em primeiro lugar, exp
 
 Se você está recebendo muitas contribuições de baixa qualidade, exija que esses contribuidores executem alguns passos antes, por exemplo:
 
-* Preencher um *template/checklist* para *issues* ou PRs
-* Abrir uma *issue* antes de submeter uma PR
+* Preencher um template/checklist para issues ou PRs
+* Abrir uma issue antes de submeter uma PR
 
-Se eles não seguirem suas regras, feche a *issue* imediatamente e aponte para sua documentação.
+Se eles não seguirem suas regras, feche a issue imediatamente e aponte para sua documentação.
 
-Embora essa abordagem possa parecer indelicada a princípio, ser proativo é, na verdade, bom para as duas partes. Isso reduz as chances de alguém se esforçar durante horas de trabalho em uma *pull request* que você não irá aceitar. E além disso, torna seu fluxo de trabalho mais fácil de gerenciar.
+Embora essa abordagem possa parecer indelicada a princípio, ser proativo é, na verdade, bom para as duas partes. Isso reduz as chances de alguém se esforçar durante horas de trabalho em uma pull request que você não irá aceitar. E além disso, torna seu fluxo de trabalho mais fácil de gerenciar.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
@@ -155,7 +155,7 @@ Algumas vezes, quando você diz não, um potencial contribuidor pode chatear-se
 
 Talvez alguém em sua comunidade, regularmente submeta contribuições que não casam com os padrões de seu projeto. Pode ser frustrante para ambas as partes passar por rejeições repetidamente.
 
-Se você perceber que alguém está entusiasmado com seu projeto, mas necessita de um pouco de polimento, seja paciente. Explique claramente em cada situação porque as contribuições deles não atendem as expectativas do projeto. Tente mostrá-los uma tarefa mais fácil ou menos ambígua, como uma _issue_ marcada como _"good first issue,"_ para que eles deem seus primeiros passos. Se você tiver tempo, considere ensiná-los a realizar sua primeira contribuição, ou encontre alguém em sua comunidade que possa estar disposto a orientá-los.
+Se você perceber que alguém está entusiasmado com seu projeto, mas necessita de um pouco de polimento, seja paciente. Explique claramente em cada situação porque as contribuições deles não atendem as expectativas do projeto. Tente mostrá-los uma tarefa mais fácil ou menos ambígua, como uma issue marcada como _"good first issue,"_ para que eles deem seus primeiros passos. Se você tiver tempo, considere ensiná-los a realizar sua primeira contribuição, ou encontre alguém em sua comunidade que possa estar disposto a orientá-los.
 
 ## Alavanque sua comunidade
 
@@ -199,7 +199,7 @@ Realizar o fork de um projeto não precisa ser uma coisa ruim. A capacidade de c
   </p>
 </aside>
 
-O mesmo se aplica a um usuário que realmente quer uma solução que você simplesmente não tem recurso suficiente para construir. Oferecer APIs e hooks de personalização pode ajudar as outras pessoas a atender as suas próprias necessidades, sem precisar que modificar o código fonte diretamente. @orta [descobriu que ](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) estimular a criação de plugins para CocoaPods levou à "algumas das ideias mais interessantes":
+O mesmo se aplica a um usuário que realmente quer uma solução que você simplesmente não tem recurso suficiente para construir. Oferecer APIs e hooks de personalização pode ajudar as outras pessoas a atender as suas próprias necessidades, sem precisar que modificar o código fonte diretamente. @orta [descobriu que](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) estimular a criação de plugins para CocoaPods levou à "algumas das ideias mais interessantes":
 
 > É quase inevitável que, quando um projeto se torna grande, os mantenedores precisam tornar-se mais conservadores sobre como eles introduzem código novo. Você se torna bom em dizer "não", mas muitas pessoas possuem necessidades legítimas. Então, em vez disso, você acaba transformando sua ferramenta em uma plataforma.
 
@@ -213,7 +213,7 @@ Uma das mais importantes formas de automatizar seu projeto é adicionando testes
 
 Testes ajudam os contribuidores a sentirem-se confiantes de que eles não quebrarão nada. Testes também tornam mais fácil, para você, revisar e aceitar contribuições rapidamente. Quanto mais responsivo você é, mais engajada sua comunidade poderá ser.
 
-Configure testes automáticos que irão executar em todas as contribuições recebidas e garanta que seus teste poderão ser facilmente executados localmente por seus contribuidores. Exija que todas as contribuições de código passem em seus testes antes que possam ser submetidas. Você ajudará a definir um padrão mínimo de qualidade para todas as submissões. [Verificações de _status_ obrigatórias](https://help.github.com/articles/about-required-status-checks/) no GitHub podem ajudar a garantir que nenhuma mudança seja aceita sem passar por seus testes.
+Configure testes automáticos que irão executar em todas as contribuições recebidas e garanta que seus teste poderão ser facilmente executados localmente por seus contribuidores. Exija que todas as contribuições de código passem em seus testes antes que possam ser submetidas. Você ajudará a definir um padrão mínimo de qualidade para todas as submissões. [Verificações de status obrigatórias](https://help.github.com/articles/about-required-status-checks/) no GitHub podem ajudar a garantir que nenhuma mudança seja aceita sem passar por seus testes.
 
 Se você adicionar testes, tenha certeza de ter explicado como eles funcionam em seu arquivo de contribuição.
 
@@ -235,7 +235,7 @@ Existem uma [variedade de ferramentas disponíveis](https://github.com/showcases
 * [mention-bot](https://github.com/facebook/mention-bot) menciona potenciais reviwers para pull requests
 * [Danger](https://github.com/danger/danger) ajuda a automatizar o code review
 
-Para relatório de bugs e outras contribuições comuns, o GitHub possui [Modelos de Issue e Modelos de Pull Request](https://github.com/blog/2111-issue-and-pull-request-templates), que você pode criar para simplificar a comunicação que você recebe. @TalAter fez o [guia Choose Your Own Adventure](https://www.talater.com/open-source-templates/#/), para ajudar você a escrever seus modelos de _issue_ e _PR_.
+Para relatório de bugs e outras contribuições comuns, o GitHub possui [Modelos de Issue e Modelos de Pull Request](https://github.com/blog/2111-issue-and-pull-request-templates), que você pode criar para simplificar a comunicação que você recebe. @TalAter fez o [guia Choose Your Own Adventure](https://www.talater.com/open-source-templates/#/), para ajudar você a escrever seus modelos de issue e PR.
 
 Para gerenciar suas notificações de e-mail, você pode configurar [filtros de e-mail](https://github.com/blog/2203-email-updates-about-your-own-activity) para organizar por prioridade.
 
diff --git a/_articles/pt/building-community.md b/_articles/pt/building-community.md
index 5d771af1986..50ebe8b3780 100644
--- a/_articles/pt/building-community.md
+++ b/_articles/pt/building-community.md
@@ -38,7 +38,7 @@ A [GitHub's 2017 Open Source Survey](http://opensourcesurvey.org/2017/) mostrou
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="avatar">
-  Contribuir com o _open source_ é mais fácil para alguns do que para outros. Há bastante medo em receber reclamações por não ter feito algo da forma certa ou simplesmente por não se encaixar. (...) Dar aos contribuidores um lugar para contribuir com pouca proficiência técnica (documentação, _markdown_ de conteúdo web, etc) reduz significativamente tais receios.
+  Contribuir com o open source é mais fácil para alguns do que para outros. Há bastante medo em receber reclamações por não ter feito algo da forma certa ou simplesmente por não se encaixar. (...) Dar aos contribuidores um lugar para contribuir com pouca proficiência técnica (documentação, markdown de conteúdo web, etc) reduz significativamente tais receios.
   <p markdown="1" class="pquote-credit">
   — @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
   </p>
diff --git a/_articles/pt/code-of-conduct.md b/_articles/pt/code-of-conduct.md
index de29b66521e..99417090d0c 100644
--- a/_articles/pt/code-of-conduct.md
+++ b/_articles/pt/code-of-conduct.md
@@ -103,7 +103,7 @@ O banimento de membros não deve ser tomado de forma branda e representa uma dif
 
 Um código de conduta não é uma lei que é aplicada arbitrariamente. Você é o aplicador do código de conduta e é sua responsabilidade seguir as regras que o código de conduta estabelece.
 
-Como um mantenedor você estabelece as _guidelines_ para a sua comunidade e as aplica de acordo com as regras estabelecidas no seu código de conduta. Isso significa tomar qualquer relato de violação de um código de conduta seriamente. Ao relator é dada a devida revisão completa e justa de sua queixa. Se você determinar que o comportamento que eles relataram não é uma violação, comunique isso claramente a eles e explique por que você não irá tomar uma ação sobre o acontecido. O que eles farão com isso é responsabilidade deles: tolerar o comportamento com o qual eles tiveram um problema, ou parar de participar da comunidade.
+Como um mantenedor você estabelece as guidelines para a sua comunidade e as aplica de acordo com as regras estabelecidas no seu código de conduta. Isso significa tomar qualquer relato de violação de um código de conduta seriamente. Ao relator é dada a devida revisão completa e justa de sua queixa. Se você determinar que o comportamento que eles relataram não é uma violação, comunique isso claramente a eles e explique por que você não irá tomar uma ação sobre o acontecido. O que eles farão com isso é responsabilidade deles: tolerar o comportamento com o qual eles tiveram um problema, ou parar de participar da comunidade.
 
 Um relato de um comportamento que não viola, tecnicamente, o código de conduta pode, ainda, indicar que há um problema em sua comunidade, e você deve investigar esse problema em potencial e agir de acordo. Isso pode até mesmo incluir revisitar seu código de conduta para esclarecer comporamentos aceitáveis ou falar com a pessoa cujo comportamento foi relatado e dizer que, embora ela não tenha violado o código de conduta, ela está no limite daquilo que é aceito e está fazendo com que os outros participantes se sintam desconfortáveis.
 
diff --git a/_articles/pt/finding-users.md b/_articles/pt/finding-users.md
index f829da01513..3ea6cf6fb88 100644
--- a/_articles/pt/finding-users.md
+++ b/_articles/pt/finding-users.md
@@ -26,7 +26,7 @@ Por exemplo, @robb usa exemplos de código para comunicar claramente porque o pr
 
 ![Cartography README](/assets/images/finding-users/cartography.jpg)
 
-Para um mergulho mais profundo nas mensagens, confira o exercício para desenvolvimento de personas de usuário da Mozilla: ["_Personas and Pathways_"](https://mozillascience.github.io/working-open-workshop/personas_pathways/).
+Para um mergulho mais profundo nas mensagens, confira o exercício para desenvolvimento de personas de usuário da Mozilla: ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/).
 
 ## Ajudando pessoas a encontrar e seguir seu projeto
 
diff --git a/_articles/pt/how-to-contribute.md b/_articles/pt/how-to-contribute.md
index a7035772d33..67468c24437 100644
--- a/_articles/pt/how-to-contribute.md
+++ b/_articles/pt/how-to-contribute.md
@@ -56,7 +56,7 @@ Não se preocupe! Há todo tipo de maneiras de se envolver com um projeto open s
 
 ### Você não precisa contribuir com código
 
-Um equívoco comum sobre contribuir para o open source é que você precisa contribuir com código. Na verdade, muitas vezes são as outras partes de um projeto que são [mais negligenciadas ou esquecidas](https://github.com/blog/2195-the-shape-of-open-source). Você fará um grande favor ao projeto, oferecendo-se para contribuir com esses tipos de contribuições!
+Um equívoco comum sobre contribuir para o open source é que você precisa contribuir com código. Na verdade, muitas vezes são as outras partes de um projeto que são [mais negligenciadas ou esquecidas](https://github.com/blog/2195-the-shape-of-open-source). Você fará um _grande_ favor ao projeto, oferecendo-se para contribuir com esses tipos de contribuições!
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/orta?s=180" class="pquote-avatar" alt="avatar">
@@ -201,7 +201,7 @@ Em vez disso, comece pensando nos projetos que você já usa ou deseja usar. Os
 
 Dentro desses projetos, sempre que você se perceber pensando que algo poderia ser melhor ou diferente, aja de acordo com seu instinto.
 
-O open source não é um clube exclusivo; é feito por pessoas como você. "Open source" é apenas um termo chique para tratar os problemas do mundo como 'consertáveis'.
+O open source não é um clube exclusivo; é feito por pessoas como você. "Open source" é apenas um termo chique para tratar os problemas do mundo como "consertáveis".
 
 Você pode ler um README e encontrar um link quebrado ou um erro de digitação. Ou você é um novo usuário e percebeu que algo está quebrado ou um problema que você acha que deveria estar na documentação. Em vez de ignorá-lo e seguir em frente, ou pedir a alguém para consertá-lo, veja se você pode ajudar. É disso que se trata o open source!
 
diff --git a/_articles/pt/starting-a-project.md b/_articles/pt/starting-a-project.md
index d4e43f9ed94..4c73a389abe 100644
--- a/_articles/pt/starting-a-project.md
+++ b/_articles/pt/starting-a-project.md
@@ -181,7 +181,7 @@ Usar um tom acolhedor, amigável e oferecer sugestões específicas para contrib
 
 Por exemplo, o [Active Admin](https://github.com/activeadmin/activeadmin/) começa [seu guia de contribuição](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) com:
 
-> Primeiramente, obrigado por considerar contribuir para o Active Admin. São pessoas como você que fazem o Active Admin esta grande ferramenta. 
+> Primeiramente, obrigado por considerar contribuir para o Active Admin. São pessoas como você que fazem o Active Admin esta grande ferramenta.
 
 Nos primeiros estágios do seu projeto, seu arquivo de CONTRIBUTING pode ser simples. Você deve sempre explicar como relatar bugs ou registrar issues, e qualquer requisito técnico (como testes) necessário para se fazer uma contribuição.
 
@@ -189,7 +189,7 @@ Ao longo do tempo, você pode adicionar outras questões frequentemente respondi
 
 Para mais ajuda em como escrever seu arquivo CONTRIBUTING, dê uma olhada no [contributing guide template](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) de @nayafia ou o ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) do @mozilla.
 
-Crie um link para seu arquivo CONTRIBUTING a partir do seu README, de modo que mais pessoas possam vê-lo. Se você [colocar seu arquivo CONTRIBUTING no repositório do seu projeto](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), o GitHub irá automaticamente 'linkar' para o seu arquivo quando um contribuidor criar uma issue ou abrir um pull request.
+Crie um link para seu arquivo CONTRIBUTING a partir do seu README, de modo que mais pessoas possam vê-lo. Se você [colocar seu arquivo CONTRIBUTING no repositório do seu projeto](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), o GitHub irá automaticamente "linkar" para o seu arquivo quando um contribuidor criar uma issue ou abrir um pull request.
 
 ![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
@@ -209,7 +209,7 @@ Para mais informações, dê uma olhada no nosso [guia do Código de Conduta](..
 
 Além de comunicar _como_ você espera que os participantes se comportem, um código de conduta também tende a descrever a quem essas expectativas se aplicam, quando se aplicam e o que fazer se uma violação ocorrer.
 
-De modo muito parecido com licenças open source, também há padrões emergentes para códigos de conduta, de modo que você não precisa escrever o seu. O [Contributor Covenant](https://contributor-covenant.org/) é um código de conduta 'pronto para o uso' que é usado por [mais de 40,000 projetos open source](https://www.contributor-covenant.org/adopters), incluindo Kubernetes, Rails, e Swift. Não importa que texto você utilize, você deve estar sempre preparado para impor o seu código de conduta quando necessário.
+De modo muito parecido com licenças open source, também há padrões emergentes para códigos de conduta, de modo que você não precisa escrever o seu. O [Contributor Covenant](https://contributor-covenant.org/) é um código de conduta "pronto para o uso" que é usado por [mais de 40,000 projetos open source](https://www.contributor-covenant.org/adopters), incluindo Kubernetes, Rails, e Swift. Não importa que texto você utilize, você deve estar sempre preparado para impor o seu código de conduta quando necessário.
 
 Cole o texto diretamente em um arquivo CODE_OF_CONDUCT no seu repositório. Mantenha o arquivo no diretório raiz do seu projeto, de modo que ele seja fácil de ser encontrado, e crie um link para ele a partir do seu README.
 
@@ -240,7 +240,7 @@ Você pode conferir o [WIPO Global Brand Database](http://www.wipo.int/branddb/e
 
 Finalmente, realize uma busca rápida no Google pelo nome do seu projeto. As pessoas encontrarão o seu projeto com facilidade? Há algo que aparece nos resultados de busca que você não gostaria que eles vissem?
 
-### Como você escreve (e 'coda') afeta sua marca, também!
+### Como você escreve (e "coda") afeta sua marca, também!
 
 Ao longo da vida do seu projeto, você escreverá bastante: READMEs, tutoriais, documentos da comunidade, responder a issues, talvez até mesmo newsletters e listas de email.