Improvement: Pull requests without links to an issue

[lurtz]

What

It shall be possible to make simple pull requests (e.g. one liners), without having to create an issue.

At the moment change_management.rst#change-request-workflow requires an issue for every pull request. For simple pull requests like eclipse-score/communication#36 this is lots of boilerplate, which slows down progress and I am afraid prevents people to write a meaningful pull requests description, because they considered their job done by the creation of the extra Github issue.

When it comes to commit message on main I like to follow what is described here: https://cbea.ms/git-commit/. I consider that more important than having to link an issue for each pull request. For each pull request and eventually for every commit on main I would like to see as title WHAT has been changed and in the description WHY it has been changed. Usually there should also be a thought process why it was implemented this or that way and give some context. As a reviewer I want to see an explanation why the pull request should be merged. What I am less interested in is a more detailed list of what has been changed.

How

For pull requests it shall be optional to link to issues. Maybe we use a pull request template in this case.

Estimates for realization

To implement this change one day should be enough.

Category

• Affects Detailed Design

Requirements / Architecture

• Requirements / Architecture are not affected by this change?

[masc2023]

Change Request are properly defined only for Feature/Component Request/Modifications, simple PRs, do not need own issue, if you do not modify concerned content of the Feature/Component. In this case you may just re-open the request and close it with the linked PR.
Making simple PR w/o issue is technical possible and not blocked. But take care, if its a bugfix, you may need create a BUG Report, especially if Safety or Security is affected.

[FScholPer]

Then I do not understand why in our doc we always have issues as default starting point of a problem https://eclipse-score.github.io/score/main/platform_management_plan/problem_resolution.html. The example was a bugfix

[masc2023]

Then I do not understand why in our doc we always have issues as default starting point of a problem https://eclipse-score.github.io/score/main/platform_management_plan/problem_resolution.html. The example was a bugfix

Bugfix issue is Problem Resolution, but not a change request
In my understanding, he asked for Change Request, https://eclipse-score.github.io/score/main/platform_management_plan/change_management.html, and that is defined only for the categories I mentioned above. Bugfix is different.

We have not yet agreed finally about the life cycle of the features (https://eclipse-score.github.io/process_description/main/general_concepts/score_lifecycle_concept.html), which means this (Problem Resolution, fixing Bugs) is mandatory at least in maintenance phase. for incubation you can anyhow develop w/o process. Change Request, resulting in modifications or new features require also Issue, at least at the begin of a Feature Life, and during official developing phase.