search

zowe / zac

Zowe Leadership Committee collaboration
Creative Commons Attribution 4.0 International
13 stars 14 forks source link

ZAC input to project maturity criteria - incubator to sub-project/squad #229

Closed armstro closed 2 years ago

armstro commented 2 years ago

In addition to describing the criteria for recommending a proposal be accepted as an incubator, when to "promote" a incubator to the open community needs documented. See TSC item https://github.com/zowe/community/issues/1228. Proposed criteria (maybe different criteria for "core" vs "extended/optional" content).

PeterFandelAtRocket commented 2 years ago

These are great. My only comment is to tweak "Has demonstrated sufficient code quality to meet TSC objectives for Zowe (doc, automated testing, etc.)" to be more explicit about integration into build & test pipeline and automated tests having been written and integrated. So "Has demonstrated sufficient code quality, automated build/test integration, and automated test coverage to meet TSC objectives for Zowe"

pdubz3 commented 2 years ago

As per my comments in #227 I don't think we should accept a new incubator unless we understand the success criteria, the capacity, the general time frame, etc. If we agree that those should be established up front, then meeting (or failing to meet) the criteria should definitely be part of the maturity or exit criteria in addition to these item you've identified.

armstro commented 2 years ago

Peter - point taken on TSC objectives ...

Mike - one comment on success criteria - do you think we know that going into an incubator? What would you say for wiZard or Mobile? .....I'm a bit more inclined to roll the dice if we think they have potential and see what happens - I think we need some discipline on pruning out stale efforts rather than managing too hard on the front end of the proposal - example - which makes me wonder what to do with mobile? I'd like to see it succeed but I don't think it is making whatever criteria we might have thought.

pdubz3 commented 2 years ago

Makes sense. If we really don't know what to expect from an incubator and we still want to roll the dice and see what happens, we should alternatively be able to set a target date for establishing the success criteria. In that case, I would hope we could at least define up front what we hope to learn that might help us to decide, and how long that should reasonably take. I want mobile to succeed also, but by now we should know what it needs to be when it grows up, and I agree that it isn't clearing any bar we might have established. In the case of mobile, there's no harm. Nobody's spending any time on it. But if we had an incubator project that was chewing up resource and going nowhere, that's the one we need to make a call on.

armstro commented 2 years ago

Don't give up on recommending some sort of criteria - maybe it is a quarterly checkpoint? What if we recommend they be able to give update at each PI planning and if they have no update we offer help (if we can) - maybe it is more publicity - maybe we look at the resource assigned - etc? If they miss 3 concurrent PIs then we take some action?

PeterFandelAtRocket commented 2 years ago

I agree to the quarterly PI update ask. We need to be less lackadaisical on incubator monitoring. It is for their own good :-)

pdubz3 commented 2 years ago

For monitoring, I agree with having regular checkpoints and PI Planning seems like a logical way to remember. (like changing the batteries on your smoke detector when you move the clocks) but you still need to have something to measure the progress against, otherwise how do you know if the progress is good?

PeterFandelAtRocket commented 2 years ago

• See pull request …/pull/1241

balhar-jakub commented 2 years ago

The yearly incubator presentation and status will happen for the first time on 9th of June. The guidelines and policies are in the https://github.com/zowe/community/blob/master/Technical-Steering-Committee/squads.md As such I am closing this issue.