Use GitHub "Projects" and "Milestones" for better repo management

[Ludee]

Description of the issue

Projects = Releases

Milestones = Goals • Bundles • Conversion • Scenario description • Issues

Ideas of solution

1. Change Milestones and Projects and harmonise naming!
2. Use same Kanban-Layout for all projects
3. Delete unused "Labels"
4. Add to documentation (contributing.md & readme)

Workflow checklist

• [x] I am aware of the workflow for this repository

[markus-rothkoetter]

Just a thought concerning swapping "Projects" and "Milestones":

From my perspective

• "Projects" are toplevel processes with a duration and dedicated sub-activities which might span across different releases
  e.g. assigning domain and range to all object properties
  AFAIK some of them are solved and others are still pending. The table-style project management on GitHub is perfect in my opinion to monitor such things.
• "Milestones" are singular points in time like snapshots where it has to be decided, if sub-activities of projects will be done by then.

So maybe it'll require some more opinions on that ...

+1 for the other three points. Especially, removing unused labels might straighten the workflow.

[l-emele]

So, if I understand you correctly you arguing for leaving the workflow basically as it is.

[Ludee]

I see the point of your definitions @markus-rothkoetter

I would focus on the practical use: The projects with custom Kanban is perfect for "sprints" like regular releases. It gives an good overview what needs to be done in short term.

A milestone gives a rough overview over the amount of solved and unsolved issues. This is used for project management and progress of the main research topics.

I could create two examples to see the differences and evaluate if it is worth the effort to switch. I think it is since I struggle to use them in the current state.

[Ludee]

I created an example and adapted the board titles to follow the workflow. For a medium amount of issues this could work.

https://github.com/OpenEnergyPlatform/ontology/projects/10

For comparison: https://github.com/OpenEnergyPlatform/ontology/milestone/13

[markus-rothkoetter]

So, if I understand you correctly you arguing for leaving the workflow basically as it is.

@l-emele Partly. I'd favor keeping the terms as is, but maybe overthinking the current use of projects. This might lead into a different direction.

@Ludee I can understand your approach as well, for me it's kind of the other way round ;) I'm flexible to adapt to the majority vote – this is valid for all remarks.

Nevertheless, I think, we should firstly asses how big the need for change is across the team.

---

Further remarks to your comment @Ludee

"Sprints" in my past projects were spanning 2-4 weeks only. This could also coincide with the regular dev-meetings. Meaning defining in the meeting the "project" for the next 2-week/4-week sprint.

The release-cycle spans sometimes months, when I see correctly. So, from a project management perspective I'd think a rough overview is required here in order to know if one is on track (current progress vs remaining time)

A third aspect might be considering something like "persistent projects" = research-areas and "volatile projects" = sprint-management. Especially with the upcoming new GitHub-Projects Feature ...

But again, let's check first if there's a broad demand

[l-emele]

Our current workflow seems to work and it seems there is no great need to change the workflow. Else someone would have responded here in the last eleven months. So I'll close this issue now.

If someone disagrees, feel free to reopen this issue.