Redmine

You could create a task for the following of the whole process and a subtask for each concerned project.

The problem with that is in order to relate tasks they need to be within the same immediate redmine project :-(

You're right, forgot that. There is issue #5487 open to change that, but actually you'll have to use the "Related issues" feature.

Hello,

I'm currently writing my master thesis to solve such problems. For the thesis, I concentrate on microservice architectures and try to build a system, which allows developers to create issues which affect more than one projects. Since I am trying to evaluate my approach it would be nice, if you could take a look at it and give some feedback. Maybe it's what you are looking for.

If you are interested, just look at the description and the mock-ups I attached to this post.

Description:

The system allows multi-project issues. Those multi-project issues are issues which affects more than one components (project or (micro-)service). Components and component interfaces can be created and connected in the system. In a graph editor component dependencies and issues can be displayed and created. Issues are displayed at the component or component interface which they are affecting. In case the user has write access, the issues are stored in component’s issue management system (GitHub, Redmine, Jira, etc.), given by the user. Otherwise they are stored in the project’s issue management system.

An issue can have a private visibility (only visible for developer of the multi-component project and stored in its issue management system) or a public visibility (only if the user has write access). Issues are classified as feature requests or bug reports. If there are already issues from a new component, which are not classified yet, they can be found under “question mark” (non-classified) and be classified from a developer in the multi-component project. It could be imagined to classify issues in future through NLP. Issues can link to other issues or artefacts (e.g. parts of a interface description file or some code). Furthermore, it is possible to add non-functional requirements, such as a runtime limit for requests to an interface. These non-functional requirements could be used in a future version to automatically reject pull requests in case they are not fulfilled. To check those requirements monitoring tools could be plugged to the system. A developer of the multi-component project can enable and disable notifications for an issue. A notification could be some note that the issue has been closed or that there is a new comment for the issue.

If a developer of the multi-component project edits an issue, for which he does not have appropriate rights, a shadow of the issue will be created in the issue management system of the multi-component project. Afterwards, only the shadow is showed. For each change of the original issue, developers of the multi-component project will be informed of these changes and can adapt the changes to the shadow, if needed. Additional, comments of the original issue are also shown in the shadow.

If a component has more than one issues of the same kind (pull request or bug report), they will be shown grouped in the graph editor. A click on an issue or a group shows a detailed view. It is possible to filter of feature request, bug report or non-classified issues.