Proposed creation of Technical Steering Commitee (TSC) for cross squad activities
Closed this issue · 26 comments
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.
Draft of key points of TSC charter:
My thoughts and proposed revisions in the attached.
Zowe.Draft.TSC.charter.-.Sept.13.2020 - Peter HACK.docx
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:
-
I went ahead and added the names of the ZLC reps to be initial members of the TSC so it would not be a mystery.
-
@pdubz3 answered your question in the text - my view is the 3 "business" members of the ZLC do not vote on the TSC - only the 3 technical members
-
@MarkAckert maybe not ideal but I said voting would be unanimous - I did not want a majority - or super majority - to be seen as over riding the wishes of another squad.....we can discuss - and include the squad leads as they are the stakeholders with something like this
• 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.
o Voting will be unanimous by the members of the TSC
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:
- How are additional technical leaders selected - I think I heard vote by committers?
- I inserted a limit to the number of TSC members to 10 - think about this - it was in response of how to limit from growing too big - if we add squads then we will need to grow the TSC
Here's some unsolicited feedback after checking out the doc. Under responsibilities, a few bullets seem "technically" oriented:
• Coordinating technical direction...
• Overseeing an architecture forum to explore new ideas...
• Have technical and architectural oversight for all the Zowe components...
• Voting on technical matters relating to the code base that affects Zowe components and squads...
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've read a few other TSC charters from Node.js and other OSS communities and merged some of their wording into the Zowe charter doc and put it in markdown here:
https://github.com/zowe/community/blob/master/Technical-Steering-Committee/charter.md
(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...
- I'd suggest renaming this from charter to proposal. We use the term charter from a legal aspect and don't want to get things confused, plus also this document seems to position more of intent and formation.
- There are a few areas where you used TSO instead of TSC ;-)
- I'd lean towards not having the ZLC involved in specifics of the TSC outside of the initial proposal. One thing that is important is to have this group take ownership, and with the ZLC shifting to more of the 'business' role it goes against the principle of how we structure communities ( technical vs business being autonomous of each other ).
- Do note that the TSC would roll up to the OMP TAC, so mediation needs should roll up to there ( again an area of technical vs business governance ). The TSC chair would have a voting seat on the OMP TAC representing Zowe.
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