Conversation
On-behalf-of: Radek Schekalla (SAP) <radek.schekalla@sap.com> Signed-off-by: Radek Schekalla (SAP) <radek.schekalla@sap.com>
rdksap
requested review from
christophrj,
enrico-kaack-comp,
maximiliantech,
n3rdc4ptn,
reshnm,
robertgraeff and
sdischer-sap
|
|
||
| ## SIG Lifecycle and Management | ||
|
|
||
| ### SIG Creation |
There was a problem hiding this comment.
would suggest to move this section to bottom. or how often do we think this happens?
the other parts affect each and everyone - always. so up
|
|
||
| SIGs operate with a **trhee-tier role structure**: | ||
|
|
||
| ### SIG Owner (Organizer/Facilitator) |
There was a problem hiding this comment.
my lazy eyes scream: give me a memorable image/artwork/diagram that gives these roles an Emoji/Tool or something to memorize when I scroll over it for the first time...
but not required for this PR to be merged.... ;-)
| SIGs operate with a **trhee-tier role structure**: | ||
|
|
||
| ### SIG Owner (Organizer/Facilitator) | ||
| - **Minimum required:** At least 1 per SIG |
There was a problem hiding this comment.
Yes. I like the aspects raised here. I would add an examle:
Owner: Approves Release builds
Approver: Approves PRs, prioririzes issue,
whatever makes sense or is applicable. but this is what we learned from the Provider interactions. People want to have a clear direction what they must, can, and must not do to work efficiently as a team
There was a problem hiding this comment.
Then it may be best to rewrite this and use RFC 2119. However, I suggest to evaluate this for some next iteration 🤔
|
|
||
| ### Decision Types and Authority | ||
|
|
||
| | Decision Type | Authority | Process | Timeline | |
There was a problem hiding this comment.
I would have stayed away from these timelines. I can imagine they are longterm relevant and important. But definitely adding lots of (really necessary?) ciomplexity to the process.
| ## Communication and Transparency | ||
|
|
||
| ### Required Communication Channels | ||
| - **Public Meetings:** At least bi-weekly, with recorded notes |
There was a problem hiding this comment.
Again, required to set frequency here? Our Groups will learn along reaction/feedback/traction I'd suggest
GenosseOtt
left a comment
GenosseOtt
left a comment
There was a problem hiding this comment.
Would have made it more concrete here and there and dont know if level of detail is doing us a favor long-term ... but no strong opinion.
The overall direction and content of this document is a great starting point. Thanks :-) Lets GOOOOOOOOOOO
Co-authored-by: Johannes Ott <johannes.ott@sap.com>
Co-authored-by: Johannes Ott <johannes.ott@sap.com>
maximiliantech
left a comment
maximiliantech
left a comment
There was a problem hiding this comment.
Nice 🚀 Thank you @rdksap! Let's go with this 🤝
9 participants
This PR adds the definition of a SIG as well as a sig-charter-template.
Content was moved from openmcp-project/docs#26
Added reviewers from TSC and from each of the SIGs. Ideally we can agree on a first version, publish it and re-iterate from there on.
On-behalf-of: Radek Schekalla (SAP) radek.schekalla@sap.com