adapt issue templates to the new fep process#81
Conversation
anmittag
left a comment
There was a problem hiding this comment.
Assuming the xxx_decision_record_template.html is available
| - Use following template within a PR and link it to this issue | ||
| [Change Management Feature Request Template](https://eclipse-score.github.io/process_description/main/process_areas/change_management/guidance/change_management_feature_template.html) needs to be used | ||
| [Change Management Feature Request Template](https://eclipse-score.github.io/process_description/main/process_areas/change_management/guidance/change_management_decision_record_template.html) needs to be used |
There was a problem hiding this comment.
Related to the possibility to having a "fast" path arround the DR for small/medium changes discussed in this comment: eclipse-score/process_description#748 (comment)
There was a problem hiding this comment.
´Change is defined, scope changes of the work products, if not, just use Task Issue Template,
| - Use following template within a PR and link it to this issue | ||
| [Change Management Component Request Template](https://eclipse-score.github.io/process_description/main/process_areas/change_management/guidance/change_management_component_template.html) needs to be used | ||
| [Change Management Component Request Template](https://eclipse-score.github.io/process_description/main/process_areas/change_management/guidance/change_management_decision_record_template.html) needs to be used |
There was a problem hiding this comment.
From the architecture communities perspective component changes would not be considered a "major" change that would need a DR. IMO if only one component is affected we should try to keep as much autonomy in the feature teams as possible and can therefore use a more lightweight process without needing a DR necessarily (e.g. continue via issue - unless the feature teams them self also demand this for changes in their features).
There was a problem hiding this comment.
Not sure, if components are used in other Modules, like baselibs, there may have server impact, if changed, if the issues is created, and the impact in the issue is rated as lightweight, no DR may required, but I see practically, that people like to use DR, just to record their decisions. Another flow may start with a bug ticket, but during investigation, impact analysis, may require a change request, as scope change is detected.
qor-lb
left a comment
There was a problem hiding this comment.
Approved as discussed - DR is optional, "lightweight" changes can use the impact analysis field in the Issue instead
According to new FEP process, Decision Record are now the main path to initiate feature/components creation and modifications.
Resolves partly eclipse-score/score#3085