Como abrir um pull request de um fork no GitHub

Um pull request é o pedido para que quem mantém um repositório incorpore uma mudança que está em outra branch ou em outro fork. Ele junta o código, a conversa sobre o código e a revisão em um só lugar. Quando a mudança vem do seu fork, os dois lados têm nomes específicos na tela: o repositório base é o original, onde a mudança vai entrar; o fork de origem é o seu, onde a mudança está.

A Open Source Guides resume o preparo: faça o fork, crie uma branch, ligue o pull request às issues relacionadas, teste a mudança e, se ela altera a aparência, mostre capturas de tela de antes e depois. Siga o estilo do projeto, e revise com atenção qualquer texto ou código que uma ferramenta de IA tenha ajudado a escrever. Rode os testes que o CONTRIBUTING indicar.

Confira também o tamanho: um pull request pequeno e com um só assunto é mais fácil de revisar. O passo a passo da primeira contribuição leva você do fork até o git push; este guia começa daí.

Segundo a documentação do GitHub, depois de enviar a sua branch para o fork:

1. Abra a página do repositório original. Aparece um aviso amarelo com o botão Compare & pull request.
2. Se ele não aparecer, use compare across forks.
3. No menu da branch base, escolha a branch do original que vai receber a mudança.
4. No menu do fork de origem, escolha o seu fork e, em seguida, a sua branch.
5. Escreva o título e a descrição.
6. Em forks de contas pessoais, você pode marcar Allow edits from maintainers.
7. Clique em Create pull request, ou use o menu ao lado para criar como rascunho.

Diga o que mudou, por que mudou e como conferir. Se a mudança resolve uma issue, escreva uma palavra de fechamento seguida do número: Closes #10. A documentação lista nove palavras que fecham a issue (close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved). Para uma issue de outro repositório, use Fixes dono/repo#100. Atenção: a issue só fecha sozinha quando o pull request vai para a branch padrão do repositório.

Um pull request em rascunho (draft) sinaliza que o trabalho ainda não está pronto, mas você quer uma opinião. A documentação diz que, em organizações, alguns membros precisam pedir esse acesso a um dono. Sobre Allow edits from maintainers: se o seu fork tem workflows do GitHub Actions, o campo vira "Allow edits and access to secrets by maintainers", o que dá a quem mantém a chance de editar os workflows do seu fork e, com isso, acessar segredos e outras branches. Marque só se entender o que isso permite.

Título: docs: corrige o link quebrado da seção de instalação

O link apontava para a página antiga do guia (https://exemplo.org/antigo).
Troquei pelo endereço atual e conferi que ele abre.

Como conferir: abra o README e clique no link da seção "Instalação".

Closes #42

Observe o formato: um título que já segue o padrão de mensagens do projeto, dois parágrafos curtos e a linha final que fecha a issue. Depois que o pull request está aberto, a revisão começa: veja como responder à revisão no passo a passo e como funciona o lado de quem avalia em revisar código dos outros.