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