-
Notifications
You must be signed in to change notification settings - Fork 14
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
Proposed creation of Technical Steering Commitee (TSC) for cross squad activities #183
Comments
Draft of key points of TSC charter: |
My thoughts and proposed revisions in the attached. |
my last update edits 2nd set of bullets to address concerns raised by Mike DuBois |
Peter, thank you. I like the updates you made. Very clear. I've uploaded a version that adds a few additional comments, one of which was about enforcement of guidelines and another was about inclusion of certain ZLC members as voting members in the TSC. But generally speaking I think this document is pretty close and we should be able to start sharing it soon. |
Thanks guys for jumping on this ..... @pdubz3 you say "share it soon" - my request is we (Peter is he can attend) float a draft to the squad leads in the 10am interlock call tomorrow that is run by the Project Manager.....clearly say it is draft - but I want them to feel a part of the process and this not handed down from zlc.......I will send email to zlc-private to be sure we are on same page ......I also think we need to get ready for voting by updating the list of committers |
I made minor changes to TSC bullets, rephrasing them. The only thing I think is missing here is a voting policy. Do voting issues require a simply majority, supermajority, or unanimous approvals to pass? For reference, the ZLC is currently supermajority. Part of why I'm bringing this is up is because we allow in the charter for new voting members to be added to the TSC - so as you add more members, all forms of majority approvals can be harder to reach. I don't have an answer to propose here yet, as I like the idea of TSC self-driven growth/change...maybe some upper bound on voting seats and/or "aging-out" of inactive voting seats/persons? |
Zowe.Draft.TSC.charter.-.Sept.16.2020.-.ma_ba.docx Minor changes:
• Drive delivery of new Zowe capabilities via discussions, seeking consensus, and where necessary, voting on technical matters relating to the code base that affect multiple Zowe components. |
Thank you @armstro ... My question may not have been clear, and it's probably my fault for poor wording. But your precise answer will actually help me to ask the question better. :-) For the first year, the ZLC appoints three technical ZLC members (Mark, Sean, Joe) to the TSC. That part I understood, but it helps to have it spelled out. And the remaining ZLC members are not voting members of the TSC, that was also clear. Fast forwarding to the second year, the TSC technical leaders are voted on by the TSC. So it's possible that one or more of those three initially appointed members (Mark, Sean or Joe) might not continue as TSC members. Or, it's even possible that one or more of them will choose to leave the ZLC, or to leave Zowe completely for that matter. Basically, my observation was that after the first year, there's no guarantee that any ZLC members will also be voting members of the TSC. So my two-part question is, "1. Do I understand that correctly? 2. Do we care?" |
Well my take is yes - you understand correctly but we need to agree this is what we want - I'm thinking we (ZLC) are kick starting the TSC and it then flies or dies on its own separate from the ZLC after year 1....and the ZLC itself flies or dies on its own - maybe with different members and not required overlap of staff (as we will have in year 1).............and yes number 2 is a valid question - do we care? I see ZLC being more outward focused (business oritented although we are not a business)....and TSC more inward focus and technical (but not limited to just inward). I was trying to keep it simple ......squad leads are the bulk of the TSC and "Additional Technical Leaders" are voted on if there are good candidates. |
Makes sense and I agree with the "flies or dies" approach. Thanks for the clarification. |
Zowe.Draft.TSC.charter.-.JRW Revision.docx @armstro - apologies for taking a while to provide input. I've attached my copy above. Wondering what the best way to proceed is to get consensus. |
Zowe.Draft.TSC.charter.V2 .docx OK - I have attempted to clean up/merge the doc and accepted all changes/comments - we are getting there. The one clause that catches my eye is the TSC "over riding" a squad and we say voting needs to be unanimous - if a squad really does not want to change something then how to handle? I assume this is a rare case but could happen. Charter will be topic for ZLC meeting today |
@armstro I understand your concern, but I think those are the teeth that the TSC requires to be effective. Enforcing a sound technical practice might not always be something everyone agrees about, but hopefully that will be a rare exception and not the norm. We don't want the TSC to take away the autonomy that the squads enjoy today, that would be bad for Zowe. But they need to have the power to steer the teams in the right direction when they're off course. |
Agreed - I am more pointing to the fact that a single squad lead could vote against the issue when all others vote for the issue and therefore not unanimous. Do we need to say something more about deadlocks that could occur in this sitation? |
Zowe.Draft.TSC.proposedcharter.V3.docx OK - sorry to late in getting this next rev out - seems every day is a fire drill. Please read and comment - two areas especially:
|
Here's some unsolicited feedback after checking out the doc. Under responsibilities, a few bullets seem "technically" oriented: The remaining seem "business" oriented. I'm curious, will it always be the case that squad leads have a clear view on architectural oversight while also coordinating releases? Should those two categories of responsibilities be split? Architecture meetings were separated before - will those be disbanded? |
Hey Dan - first realize the document is a draft. This is "opening bid" for listing responsibilities subject to input from the squad leads, architects and what I called "Additional Technical Leaders" (that could be DEs? Customers? ISVs? or anyone else). Answering the Architecture meeting question first - it will not be disbanded unless there is some reason to do so that I am not aware of - I hear comments its one of the best meetings for the technical community - part of the point of the TSC is to gain agreement to act on the ideas from the Architecture meeting. I guess I am not sure the remaining responsibilities are "business" but they are maybe "style" oriented - being transparent, gaining consensus, etc. - but point taken they are not all "technical". If I had to single out one statement about the TSC, I would pick this one: "Establish minimum cross squad policy for the development, build, test, and documentation process for Zowe – this to include acceptance criteria for new source code." Keep in mind this policy is to be made by the stake holders themselves - this is not a top down dictate. Others may pick other points to highlight but this gets to issues like the importance of automated tested, code quality, etc. To your question - "will it always be the case that squad leads have a clear view on architectural oversight while also coordinating release" - I think squad leads should have some understanding of the architecture - I am not sure "clear view" is the right term - the TSC should include architects like yourself that has the "clear view" and the squad leads should be able to interact with the architects in the TSC with Q&A, etc. Another point - I am not sure squad leads are "coordinating release" - they are coordinating their contribution to a release - the project managers, build team, doc and web editors are also involved in the coordinating. We are trying to have the TSC be the hub of much of that activity. So thanks for feedback - we WILL solicit feedback from everyone and hope we can get consensus on the need for a TSC and then agree on charter. |
Thanks @armstro for taking the time to to respond and clear things up for me a bit. I'll hang tight and keep an eye out for this to finalize 😀 |
@dkelosky please get involved and help define the TSC - I think the formation of the TSC is a sign of the community growing in maturity. The ZLC has worked well the last couple years to get us started but the technical leadership needs to control such things as when releases are ready, look for areas of improvement in quality, improve integration, etc. We hope to get this vetted quickly and established in 4Q - in many ways we are just putting a structure in place for what I think already happens informally - squad leads talking to squads leads, interlocks with doc and Systems Team, hashing out implementation issues on cross squad deliverables. TSC is more evolution and revolution {8-). |
@armstro and others - this is looking really good with a lot of great input and feedback. (I can't merge this into the ZLC repo because of github size issue that we can resolve separately, but I propose going forward that we collaborate on the https://github.com/zowe/community/blob/master/Technical-Steering-Committee/charter.md file for revision history). The remaining piece seems to be having each squad propose who they want to represent them. |
Hey @Joe-Winchester - overall like the content. A few thoughts...
Let me know if this all makes sense...happy to discuss in more details or make a PR with changes if that helps. |
Made a revision that hits the items above at zowe/community#795 |
Closing - TSC created, staffed and charter in discussion. Positioning of ZLC and TSC is work in progress. See #220 for additional info |
Following the CUPIDS work for SMP/E and componentization - proposal is to have an ongoing TSC to help facilitate future integration activities - example include (but not limited to) single sign on, multi-factor authentication, high availability, containerization, etc. This issue is to sketch out the mission of such a TSC.
The text was updated successfully, but these errors were encountered: