diff --git a/ebook/10.-pull-requests-no-github/10.1-o-que-e-um-pull-requests-no-github.md b/ebook/10.-pull-requests-no-github/10.1-o-que-e-um-pull-requests-no-github.md
index 78f5c75..6d7caab 100644
--- a/ebook/10.-pull-requests-no-github/10.1-o-que-e-um-pull-requests-no-github.md
+++ b/ebook/10.-pull-requests-no-github/10.1-o-que-e-um-pull-requests-no-github.md
@@ -7,17 +7,35 @@ Imagine que um grupo está escrevendo um livro em conjunto. Cada pessoa escreve
 * Ele é um pedido para que alterações sejam revisadas e incorporadas ao projeto.
 * Em vez de modificar diretamente o código do projeto, a pessoa sugere mudanças e pede a aprovação de outras pessoas.
 
-## Como Era Feito Antes?
-
-Antes da existência dos PRs, colaborar em um projeto era muito mais complicado. Imagine que duas pessoas estão escrevendo um livro juntas, mas cada uma está usando um caderno diferente. Para juntar os textos, era preciso mandar as páginas por carta ou e-mail, e a outra pessoa teria que copiar e colar manualmente no livro final. Se houvesse erros ou sugestões, o processo de revisar e modificar seria bem mais demorado.
-
-No mundo do desenvolvimento, antes dos PRs, as mudanças no código eram enviadas por e-mail em arquivos separados. Quem administrava o projeto tinha que baixar, comparar e juntar tudo manualmente, o que aumentava o risco de erros e tornava a colaboração muito mais lenta.
-
-Os **PRs foram criados para facilitar esse processo**, trazendo:
-
-* **Revisão de código integrada**: Outras pessoas podem comentar e sugerir melhorias.
-* **Histórico claro de alterações**: O GitHub mostra exatamente o que mudou.
-* **Menos erros**: Como há revisão antes da fusão (merge), menos _bugs_ chegam ao código principal.
+## Outros modelos...
+
+O GitHub introduziu o modelo de Pull Requests, como uma visão alternativa para o
+modelo tradicional que o git foi desenvolvido. Funcionalidade essa que foi adota
+por outros serviços de hospedagem de código, como o GitLab, Bitbucket, codeberg,
+entre outros. Lembre-se, o git em si é um sistema distribuido de controle de
+versão, e não uma plataforma centralizada de hospedagem de código. Isso
+significa, entre outras coisas, que o git foi desenvolvido para ser trabalhado
+de forma distribuida, através do e-mail, que por si só é um sistema distribuido
+(você pode enviar e receber e-mails de qualquer provedor do mundo). Portanto, o
+git, em sua essência, tem a habilidade de distribuir os códigos e mudanças
+gerando um patch (remendo em inglês) que pode ser enviado por e-mail para
+qualquer pessoa, e essa pessoa pode aplicar esse patch em seu repositório local.
+
+A parte do distribuido entra nesse aspecto, porque, esse modelo, para funcionar
+(tal qual o kernel do Linux, o próprio git, e muitos outros projetos open
+source) precisam ter uma lista de emails para onde essas mudanças são enviadas e
+naturalmente, qualquer pessoa que subscrevesse essa lista de e-mails poderia
+contribuir com a discussão e o desenvolvimento do projeto. Esse modelo é,
+naturalmente, mais complexo e mais lento do que o modelo de Pull Requests,
+visando que o mesmo consegue centralizar e manter referência de todas as
+mudanças propostas em um único lugar, facilitando a revisão e o gerenciamento
+das contribuições.
+
+Os **PRs facilitam esse processo em um modelo mais centralizado**, trazendo:
+
+* **Revisão de código integrada**: Outras pessoas naquele repositório podem comentar e sugerir melhorias.
+* **Histórico claro de alterações**: O GitHub mostra um histórico das versões e o que mudou.
+* **Integração com outras funcionalidades do GitHub**: O GitHub pode rodar testes automáticos, verificar conflitos e muito mais.
 
 ## O nome "Pull Request"