-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create KIT Issue Template #983
Create KIT Issue Template #983
Conversation
Co-authored-by: Arno Weiß <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is important to mention and link to our TRGs. For example, we have the TRG 9.01 especially for KITs:
https://eclipse-tractusx.github.io/docs/release/trg-0/trg-9-01
The feature template should include a checkbox to validate if it confirms the relevant TRGs.
Maybe this could make more sense to include it in a pull request template for KITs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine for me, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine for me
The template is for KIT Feature proposals during planning not for the QGate Tickets. Thus, I would not mention the TRGs already at that state. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small improvements and one big question: Do we really want the architectural relevance checks in the feature template? Similar to my comment on the TRGs, the architectural relevance may be checked only during QGate.
As no KITs are creaed if no standard exists, the architectural relevance should have already been gatekeept on standardization level.
- [ ] [CX-0001 EDC Discovery API](https://catenax-ev.github.io/docs/next/standards/CX-0001-EDCDiscoveryAPI) | ||
- [ ] [CX-0002 Digital Twins in Catena-X](https://catenax-ev.github.io/docs/next/standards/CX-0002-DigitalTwinsInCatenaX) | ||
- [ ] [CX-0018 Dataspace Connectivity](https://catenax-ev.github.io/docs/next/standards/CX-0018-DataspaceConnectivity) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove empty line
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"As no KITs are creaed if no standard exists" -> I would not say that this is always the case. And often it is only visible in the KIT how the standard is going to be applied.
To my mind, it helps to bring the guidelines as soon as possible to awareness.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"As no KITs are creaed if no standard exists" -> I would not say that this is always the case. And often it is only visible in the KIT how the standard is going to be applied. To my mind, it helps to bring the guidelines as soon as possible to awareness.
Technically @eckardg is right - see maturity level "Sandbox": https://eclipse-tractusx.github.io/documentation/kit-maturity-levels/), but I still agree with @tom-rm-meyer-ISST here. As a KIT at the Sandbox-stage provides only a "vision" and business objective, the guardrails can not be applied in a meaningful way at this stage. And for the next maturity stage "Incubating", standards are already mandatory.
Personally I would prefer just one additional check with "This feature aligns with our current set of standards."
Co-authored-by: Tom Meyer <[email protected]>
Co-authored-by: Lars Geyer-Blaumeiser <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@tom-rm-meyer-ISST you requested changes, is this done? Thx :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for incorporation. This is lean and not mentioning the TRGs makes sense.
Just a comment: line 26 and 27 is a duplicate blank line that has not used between headings elsewhere. But changing this would make "reassessment" necessary.
1cac38a
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Description
Created KIT Issue Template with topics
Pre-review checks
Please ensure to do as many of the following checks as possible, before asking for committer review: