Milestones and Projects on Github

Asked

Viewed 141 times

2

I’m using github for my personal projects.

One of the things I like the most is that he has several tools to help me, not only control the source but also what was done.

One of the interesting options is the issues. They are project offsets that can be opened by the repository owner or any member of github.

They have some category options.

Doubt

What is the difference between Milestones (Flap Issue) and Project (Flap Projects)?

They both work very well to control progress, but I wanted to know the usefulness of Milestone in a project with projects configured.

  • Related: https://answall.com/q/345326/101

1 answer

2


The concepts of issues and Projects are not competitors but collaborative. The concepts, according to Github’s help, are:

  1. Issue: Use it to track ideas, improvements, tasks or bugs. (source: https://help.github.com/articles/about-issues/)

That is, it is your smallest working logging unit, if you need to implement an improvement, fixing a bug creates as Issue.

For example, below I created a Issue reporting an error that must be corrected, but note that already on this screen there is the field Project (1).

Após criado um *issue* é possível adicioná-lo a um projeto

The concept of project inside the Github is:

  1. You can create project Boards for the development of a Feature specific, create a roadmap, or what will go on a certain release checklists (source: https://help.github.com/articles/about-project-boards/)

It’s basically project control, and when I create one, I can add issues in it, for example, what I created in the previous item:

Após criação de um novo projeto, a aba lateral direita permite a adição de *issues* existentes

And lastly:

  1. Milestone also aggregates several issues, and with this it is possible to set as goals (source: https://help.github.com/articles/about-milestones/)

Below I put a Issue both in a project, and in a Milestone:

A *issue* é categorizada tanto no *milestone* 1.0.0 como no *project* Melhorias da aplicação para versão 2

The idea is: repository users record problems or suggestions in issues, the repository administrators will sort if it makes sense, and may include it in a project in the future. The project by definition has beginning, middle and end; so by creating it you determine which work items will enter the project, or you can add over time; when the project has completed its goal, it ends. At the end you have a release and this can be represented by a Milestone, in the case of the above examples with the name 1.0.0.

  • Good evening. I could understand, it was as I imagined. Milestones how much the Projects are used to group the issues, but the focus of the grouping for deliveries fits better for the Milestones. Os Projects would be at the discretion of those who had managed the project, being able to separate both by functionality and by the delivery itself, depending on what fit best. Correct me, please, if I’m wrong. Thank you for the answer.

  • 1

    I think it might be the way you put it. Understand that this is a logical grouping, it is worth more the sense you give and if it is bringing benefits to you than following some pattern.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.