Qual é a diferença / relação entre os projetos do GitHub e os marcos?

A recente atualização do GitHub adicionou algo chamado Projetos ao fluxo de trabalho do GitHub e, como não tenho nenhuma experiência em particular com ferramentas de rastreamento de projetos como Jira ou Trello (ei, pelo menos notei a semelhança) , alguém poderia, por favor, elaborar sobre as (principais) diferenças entre os marcos do GitHub e os novos projetos ?

Se bem entendi, os Marcos são uma maneira de organizar os problemas em "subprojetos" menores - menores que o "projeto" completo (que, na minha visão de mundo, é representado pelo repositório ). Quando todas as questões estão concluídas / fechadas, o marco pode ser considerado completo .

Os Projetos recém-introduzidos também são, a meu ver, uma maneira de organizar os problemas em "subprojetos" menores que o repositório (embora chamados de Projetos ). Entendo que o fluxo de trabalho deve ser um pouco diferente e mais refinado do que com "meros" Marcos .

Então, os Projetos são algo que complementa Marcos (ou melhor, Marcos complementam Projetos agora?) Ou devo preferir ver os Projetos como um substituto dos Marcos ?

Onde exatamente os Projetos realmente se enquadram na repository[-milestone]-issuehierarquia?

Infelizmente, a entrada de blog do GitHub sobre a introdução dos Projetos não menciona nenhum relacionamento ( https://github.com/blog/2256-a-whole-new-github-universe-announcing-new-tools-forums-and- recursos ).

De alguma forma, sinto que há um, mas não consigo identificar.

Eu estou pensando exatamente a mesma coisa. Aqui está o que eu vim com.

Primeiro, vamos revisar as principais semelhanças e diferenças:

• Um problema pode pertencer a vários projetos, mas apenas a um marco.
• Projetos nunca estão completos . Não há barra de progresso ou prazo. Os projetos não têm barra de progresso ou prazo, mas agora podem ser encerrados (conforme apontado por @Sheen)
• Os marcos, por outro lado, têm tudo isso, mas carecem de qualquer forma de organização. Um problema está em um marco ou não está. (Eles podem ser solicitados conforme indicado por @Nick McCurdy)
• Os problemas podem ser filtrados pelo Marco, mas não pelo Projeto. Conforme apontado pelo @cmonkey, os problemas agora podem ser filtrados pelo Project e pelo Marco.
• Os projetos podem conter notas (que podem ser convertidas como problemas), para que não poluam o rastreador de problemas com idéias vagas
• Um projeto pode se estender por vários marcos e um marco contém partes de diferentes projetos.
• Uma organização também pode ter projetos. Esses projetos podem incluir tickets de qualquer repositório da organização, o que o torna bastante útil.

Então, a meu ver, os Projetos são uma maneira completamente separada de visualizar e organizar seu trabalho em um nível superior (pense em "gerenciamento de projetos", várias equipes, vários repositórios etc.), enquanto os Milestones são uma maneira de organizar seu trabalho. prazos e lançamentos em um nível mais básico (pense em "gerenciamento de lançamentos", "versões" etc.). Com isso em mente, faz sentido que um problema pertença apenas a um marco (ele é lançado ou enviado à produção apenas uma vez), mas pode fazer parte de diferentes projetos.

Tenho certeza de que existem outras maneiras de analisar o assunto e estou interessado em ouvir outras opiniões.

Editar dezembro de 2017

Há algum tempo, depois de trabalhar com Milestones e Projetos por mais de um ano, percebi que havia outro aspecto importante que eu havia ignorado completamente.

• Milestones é uma ferramenta para a metodologia Scrum . Os marcos são bons para iterações com timebox e para trabalhar em sprints com lotes de problemas.
• Projetos é uma ferramenta para a metodologia Kanban . Os projetos são bons para entrega contínua e fluxo constante de trabalho.

Minha opinião:

• Um projeto é sobre um processo e as pessoas .
• Um marco é sobre um produto .

Um projeto é melhor para obter informações sobre um processo usado pelas pessoas do grupo. Um nome melhor para isso seria "fluxo de trabalho" ou "processo". Há mais custos envolvidos na criação de um novo projeto do que na criação de um novo marco. Então, você realmente só deseja criar um novo projeto quando houver um novo processo em sua equipe: as faixas devem ser escolhidas, configuradas e ordenadas. Eles também podem ser muito diferentes em cada projeto. Penso novamente no uso original do Kanban pela Toyota: gerenciar as pessoas e sua carga de trabalho.

Um projeto responde à pergunta: "No que estamos trabalhando no momento?"

Dois ótimos exemplos de projetos: desenvolvimento de software e blogs. As configurações de cada um suportariam os processos de pessoas dos diferentes grupos; como eles trabalham juntos e assinam as coisas.

Marcos, ao contrário, todos funcionam da mesma maneira. Eles são uma lista ordenada de tarefas que devem ser fechadas para que o produto de trabalho seja considerado completo. Opcionalmente, uma data de vencimento pode ser definida, o que apenas fornece lembretes, mas não altera o funcionamento do Marco.

Um marco responde à pergunta: "O que resta para terminar este produto?"

Uma coisa legal dos projetos é que eles são mais de forma livre do que marcos. Você pode apenas fazer anotações nelas e vincular-se a problemas e organizá-las da maneira que mais lhe convier. Eles são ótimos para anotar idéias, criar roteiros e listar recursos e dependências. No passado, eu usei problemas e o wiki para as mesmas coisas, mas achei ambos muito formais e transacionais (ou seja, maior sobrecarga).

Marcos são tipos de etiquetas que marcam e agrupam tickets que devem ser entregues em algum momento. A Milestonespágina que você pode acessar a partir da Issuespágina deixa claro - você pode ver a porcentagem de tickets concluída para um determinado marco e a data de vencimento. Você também pode classificar marcos por data de vencimento e priorizar tickets em um marco específico.

O estresse aqui está nas datas de entrega e no acompanhamento do progresso.

Por outro lado, os projetos são implementados no GitHub como placas Kanban com alguns sinos e assobios. Você pode especificar um número de colunas ( e raias - como @Doug disse abaixo raias ainda não são suportados) para criar fluxos de trabalho simples. Você pode adicionar tickets de um ou vários repositórios, priorizá-los e progredir de uma coluna para outra à medida que eles estão sendo trabalhados. Você pode, por exemplo, ter as colunas 'Backlog', 'Em andamento', 'Em revisão', 'Em teste' e 'Concluído' e mover tickets da esquerda para a direita ou da direita para a esquerda se, digamos, com defeito o ticket é devolvido de 'In Testing' de volta para 'Backlog'.

A ênfase aqui está na organização e gerenciamento do trabalho.

Então, como você organiza e particiona esse trabalho é com você. Você pode criar um projeto por marco ou ter vários marcos em um único projeto ou dividir marcos em sprints mais curtos . Você também pode ter vários projetos que abrangem diferentes aspectos do trabalho no produto, por exemplo, um para desenvolvedores e outro para testadores.