Define procedure for MCP collaboration

[henrikt-ma]

Eager to get started on the next steps of MCP-0031, see bottom of
https://github.com/modelica/ModelicaSpecification/blob/MCP/0031/RationaleMCP/0031/99thDesignMeetingNotes.md
I just made a quick test to see what it would be like to filter out MCP-related pull requests when one is only interested in the pull requests on master.

Filtering is as easy as adding the search term base:master, and it is easy to create a URL that delivers this result:
https://github.com/modelica/ModelicaSpecification/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster

I think this solution has a great advantage in not having to do the administration of tags with a one-to-one correspondence to branches. By the way, there are currently 8 open pull requests on master, so we are already quite far away from a clean count of zero open pull requests. Hence, adding the counts for pull requests on MCP branches wouldn't hurt in this respect either.

[henrikt-ma]

I was going to assign this to Lennart Ochel, in line with the notes from the design meeting, but I'm afraid he doesn't have an account yet. Is that right?

[sjoelund]

@lochel has an account. I have now invited him to the github organization as he's now a member

[henrikt-ma]

Good! He seems to have accepted, since I was able assign this issue to him. :)

[lochel]

Using pull requests as described by @henrikt-ma doesn’t enable discussions in a nice way, because a pull request always implies a commit (not necessarily containing changes). In practice, this means that a dummy commit would be required to start a discussion.

Another option would be to use github projects. Projects can be used to organize a subset of issues and pull requests. The subset could be further divided into categories to improve the workflow. However, you cannot filter issues/pull requests by projects, which would make the main lists of issues and pull requests unclear. This is only possible with labels and milestones.

If we assume that we want to keep the entire development in the main repository, labels (or milestones) seem to be the way to go. There should be one label for each MCP that gets assigned to all related issues and pull requests. This would make the main lists of issues and pull request clear and they could be filtered. Also, it doesn’t require keeping the project boards up-to-date, which would probably introduce some overhead.

[miscco]

I would disagree. What you describe are "Issues". In the earliest stage before an implementation is even known the better way would be to simply open an Issue and start discussing there. Once there is some form of MCP-rational one can open a PR.

I would believe that an MCP without any kind of wording/rational is rather unlikely

[lochel]

The starting point of an MCP would probably always be a pull request. Maybe even a draft pull request with some good discussion before merging. However, after that there could be more pull requests to incorporate further changes and there could also be general discussions starting without any proposed changeset. Therefore, we need a nice way to filter/group both issues and pull requests for a specific MCP. As I described earlier, the best way doing this is in my opinion using labels.

[HansOlsson]

I agree that having labels for the discussion relating to each MCP makes sense, as it doesn't seem possible in other ways to attach an issue to a specific branch/Pull Request. Unfortunately that also implies that keyword-closing of issues will not work well for this case.

I would propose labeling issues related to e.g., MCP0031 with both MCP and MCP0031 and use the label-description for MCP0031 to describe what the MCP is about.

The reason for both is to be able to exclude MCPs from other searches, since it seems that GitHub label-search doesn't support wildcards.

The other option would be to use MCP-specific Milestones instead, but the wild-card issue rules that out. (Advantage: Only one milestone and separate from everything else, Disadvantage: Looks weird, and we cannot use Milestone for meetings.)

However, I would propose we add these labels when needed, and with that we can close this issue. (I guess we could use "Project Boards" to get a better overview) There is now a proposal for an updated work-flow, #2412 - and I don't think we need the details for labels in that document yet.

[HansOlsson]

It seems that has been implemented a bit, and by better discipline of labelling issues it seems the problem is reduced so I will close it until we get new proposals.