Se voc\u00ea faz algum trabalho \u2013 independentemente de ser de c\u00f3digo aberto ou de c\u00f3digo fechado \u2013 (embora eu saiba que a maioria dos que usam este site est\u00e3o envolvidos em c\u00f3digo aberto), voc\u00ea provavelmente usa algum controle de origem, e provavelmente \u00e9 o GitHub.<\/p>\n
Para muitos de voc\u00eas, voc\u00ea segue um projeto, contribui para um projeto ou lida com pull requests para um projeto. E os projetos em que voc\u00ea trabalha em equipe?<\/p>\n
Talvez seu fluxo de trabalho seja algo assim:<\/p>\n
Mas o que voc\u00ea coloca no modelo para o pull request? \u00c9 sempre o mesmo ou \u00e9 diferente? E se o conte\u00fado do PR estiver relacionado a algo no Trello<\/a>, Asana<\/a>, Basecamp<\/a> ou algum outro sistema de gerenciamento de projetos?<\/p>\n \u00c9 a\u00ed que os modelos de rela\u00e7\u00f5es p\u00fablicas do GitHub entram em a\u00e7\u00e3o.<\/p>\n Voc\u00ea pode ler tudo sobre eles na p\u00e1gina, mas aqui est\u00e1 a ess\u00eancia (sem trocadilhos):<\/p>\n \u00c9 dif\u00edcil resolver um problema quando faltam detalhes importantes. Agora, os mantenedores do projeto podem adicionar modelos para problemas e solicita\u00e7\u00f5es pull aos projetos, ajudando os contribuidores a compartilhar os detalhes corretos no in\u00edcio de um t\u00f3pico<\/p>\n<\/blockquote>\n E a ideia \u00e9 simples: criamos modelos para problemas e pull requests para outros que fornecem um n\u00edvel de informa\u00e7\u00e3o que eles devem preencher antes de enviar um problema ou um pull request.<\/p>\n Isso nos ajuda, pois os mantenedores sabem qualquer informa\u00e7\u00e3o que precisamos antes de analis\u00e1-la. Al\u00e9m disso, pode nos permitir vincular a um problema anterior, ticket anterior, anterior a qualquer coisa relacionada ao projeto.<\/p>\n Por exemplo, digamos que voc\u00ea esteja trabalhando em um projeto e queira incluir as seguintes informa\u00e7\u00f5es:<\/p>\n N\u00e3o estou dizendo que esta \u00e9 a informa\u00e7\u00e3o necess\u00e1ria, mas \u00e9 algo que usamos e achei \u00fatil (e \u00e9 bom ver mais melhorias sendo feitas ao longo do tempo<\/a> ).<\/p>\n O site \u00e9 bem claro, mas \u00e9 bem simples. Voc\u00ea precisa dos seguintes arquivos no diret\u00f3rio do seu projeto ou no arquivo. diret\u00f3rio do github<\/strong> :<\/p>\n Cada um deles deve ser um arquivo markdown que mostra exatamente o que voc\u00ea est\u00e1 procurando para que seus contribuidores incluam sempre que eles estiverem, voc\u00ea sabe, contribuindo para o seu projeto de alguma forma.<\/p>\n E ent\u00e3o, sempre que um usu\u00e1rio procura relatar um problema ou criar uma solicita\u00e7\u00e3o pull, ele solicita as informa\u00e7\u00f5es do modelo.<\/p>\n Legal, n\u00e3o \u00e9?<\/p>\n Voc\u00ea pode achar que n\u00e3o \u00e9 muito, mas \u00e9 muito f\u00e1cil ajudar a melhorar a qualidade das informa\u00e7\u00f5es que chegam a um projeto, fazer com que seus colaboradores pensem sobre o que est\u00e3o colocando no projeto e ent\u00e3o respondam de acordo.<\/p>\n Al\u00e9m disso, ajuda voc\u00ea e o restante de sua equipe a entender o que est\u00e1 prestes a ser revisado e a se preparar para quaisquer mudan\u00e7as que possam surgir ao trabalhar nesses projetos.<\/p>\nModelos de rela\u00e7\u00f5es p\u00fablicas do GitHub<\/h2>\n
\n
\n
Mas como usamos isso?<\/h3>\n
\n
N\u00e3o \u00e9 muito, mas\u2026<\/h2>\n