ZAC input to Zowe Principles

[armstro]

TSC is authoring Principles for the community - see https://github.com/zowe/community/issues/1136 extracted from: https://github.com/cncf/toc/blob/main/PRINCIPLES.md - this issue is for ZLC/ZAC to provide input to the TSC process.

I will not duplicate all the material here in the links above - only summary for context and comments on where Zowe might differ. We may want to just insert our comments to issue 1136 but I thought we would start here. Pull request here https://github.com/zowe/community/pull/1242 is work in progress.

• Project centric - (this is in the CNCF principles but not mention by TSC) - recommend we say something about _integrated _projects__ maybe something like (paraphrasing) the intent is the "whole is more than just the sum of the parts"?

Agree with TSC on the following with some tweaks -

• Squads are self-governing Principle: Minimal Viable Governance

• We are looking to grow or have contributed high-quality, high-velocity projects that fit ‘mainframe’ and integrate to the distributed and cloud environments. Principle: Great projects already have many ingredients to succeed. First: do no harm.

• Not a Standards Body Principle: Zowe promotes interoperability via industry standard or defacto interfaces that get real-world use Important: Principle of Interoperability

• Above All, We Want To Help Squads - Principle: Our top priority is helping high-quality high-velocity mainframe open source projects be the main driver of customer adoption and success

Other principles proposed

• Security in the Zowe is paramount - we commit to secure development practices, source code scans and vulnerability testing. If vulnerabilities are ever found they will be #1 priority to resolve. Any code in the core long term support release with an unresolved severe vulnerability will be flagged as do not use (PE in z/OS terminology) and fix or workaround provided.
• Zowe is developed for the good of the z/OS platform. We will not harm the z/OS vendor ecosystem. Zowe will be vendor-neutral in what the core components deliver.

What else?

[PeterFandelAtRocket]

Feature space defined as "projects that fit ‘mainframe’ and integrate to the distributed and cloud environments". These words do imply "distributed" interfaces, but should we be more explicit and add a few words about meeting contemporary (not Z-specific) interface expectations (standards, tools, programmatic and graphical)?

[balhar-jakub]

This is where we (TSC) collect our input to the discussion: https://github.com/zowe/community/pull/1242/files

It seems that in general, we are looking in the same direction.

[armstro]

I like the TSC list - I am fine with Peter's point using contemporary interfaces (although I am not real sure of the right term to use) - I think the days of "distributed" and "mainframe" will fade away with the shift to containers - what do we call containers? contemporary technology?

I have thought of two other principles for discussion (that is already somewhat mentioned) .....

1) I don't think the mention of squads, user and data driven and self governance is complete enough - I am thinking we say we believe in Agile Development principles https://www.scaledagileframework.com/safe-lean-agile-principles/? Small teams, iterative development, etc.- I know they mention "products" but open source can be a "product" (deliverable).

2) I am also thinking under the spirit of "do no harm" to say something about Zowe is focused on integration, to add value to the mainframe and foster IT staff productivity ..... I am also thinking to say the intent is to not compete with any commercial offerings but provide technology to grow z/OS adoption and use?

[PeterFandelAtRocket]

Leave open pending TSC completion for one more review by ZAC

[pdubz3]

This is complete.