Draft policies for handling of support issues by Zowe Support Providers

[armstro]

Zowe Support Providers should consider support policies when working with consumers of Zowe technology - some recent examples to use as scenarios for consideration

• Prior situation - when/how to hand-off customer issues between support suppliers (including z/OS Support) • What visibility to have in the open community to cases being worked - how do we share areas of improvement (doc, testing, ...) • If customer not entitled to support (for whatever reason) how to hand off to community

[armstro]

Zowe zED Talk Jun1 2023 subset.pdf

On Jun 1 I presented to a small IBM and customer community called zED Talks modeled after TED Talks. Attached is a subset of the deck (I removed most of the IBM specific content). I will post recording when it is available.

I would like to use this as the starting point for Zowe Support Conformance discussion update. My main purpose is to have consistency in messaging to Support consumers but also consider some "best practicies" on how we engage the Zowe community to assist with Support issues. Please review deck - especially:

• Page 10 vendor specific bullets (value adds we may provide as vendors)
• Pages 14-17 regarding Support considerations (I am not sure my description is true for all Support providers)

I'd like to put this on the next ZAC and consider spinning up a working group among the Support Providers.

[jmertic]

I won't be at this week's ZAC meeting as I'm on PTO this week, but can make the one on 6/13

[pdubz3]

Broadcom is hosting a customer event next week so Rose, Mark and I will be traveling. It's unlikely that any of us will make the ZAC call on the 13th. :-(

[armstro]

https://ibm.box.com/v/zedtalks2023 has recording with the "words that went with the slides" posted above.

[jmertic]

Are there updates/next actions on this?

[armstro]

No updates - I have the to-do to better describe the issue and bring to ZAC .....

[armstro]

Propose to include the "fragmentation image" concern with this issue - topics:

• What does fragmentation mean? - Zowe distributions are somehow different from different sources. The fact is Zowe is the same but the packaging and "value adds" (extra stuff) may be different. (Different packaging and adds on are allowed.)

• Do we have a fragmentation image issue - is it isolated or pervasive?

What are the messages we want to communicate?

• A Zowe core version and release is the same regardless of where it is obtained (zowe.org or Support Provider). May need to help define what "core" means for the consumers.

• One Support Provider will recognize another vendors/community Zowe distribution assuming the code can be authenticated as geniue ("fingerprint" app for z/OS components, matching hash for client slide components). There are allowances for emergency fixes but those are to be contributed back to community.

• Consumer should not need to "swap out" one distribution for another from Support Provider in order to obtain Support (may need to upgrade to latest for fixes) - https://www.zowe.org/support.html

• How to communicate Zowe is Zowe to our consumers?

• Badging "Authenticated Zowe Inside"

• Blog?

• Documentation? Community, vendor, both?

• From Zowe consumer - involves changing packaging - ISV plugins should be delivered as separate add ons and not as an "out of the box" feature, reason for that is, if a customer decides to move their Zowe support somewhere else, they don't need to reinstall to be supported.

• Education of Support Providers L2 teams to be sure there is clean understanding of Support policy

Zowe.Support.Provider.-.Test.Evaluation.Guide.Table.pdf

Zowe.Conformance.Program.-.Terms.and.Conditions.pdf

[armstro]

Proposed text from Paul regarding cross Support Provider policy "We understand that there might be some confusion regarding the Zowe bundles offered by different vendors. We would like to clarify that these bundles are not different versions of Zowe; rather, they include the open-source Zowe framework along with additional utilities provided by the respective vendors. Zowe itself remains consistent across these offerings, ensuring a standardized experience regardless of the bundle you choose. These utilities are designed to complement Zowe's capabilities and provide enhanced functionalities, but they do not alter the core Zowe framework. Rest assured, no matter which bundle you select, you will be working with the same version of Zowe. If you have any further questions or concerns, please do not hesitate to reach out to our support teams."

[pdubz3]

Renewing my caveat that it depends on which vendors we're talking about. We need to be more clear about this. The fact is that the Zowe community and all of the Zowe-conformant support providers are committed to a vision that includes a single, genuine version of Zowe and we discourage any distribution of Zowe that varies from the genuine content you can acquire from www.zowe.org. That does not prohibit any vendor from distributing additional value in the form of Zowe plugins or extensions along with their genuine Zowe distribution. However, the vendors contributing to the Zowe community stand together in their commitment to a single, genuine Zowe regardless of where or how that genuine Zowe is acquired.

My personal opinion is that we need a complete document that describes in detail all of the obvious nuances. For example, what qualifies as a distribution of Zowe? Server? Client? Both? Core? Other? Furthermore, I believe that the document should be linked to www.zowe.org and that a clear, visually recognizable icon should be paired with that link so that any customer seeking a genuine Zowe distribution can recognize one just by the existence of that icon. Asking every customer to read and interpret and understand the nuances is too much to ask, in my opinion.

On Tue, Aug 29, 2023 at 11:09 AM Bruce Armstrong @.***> wrote:

Proposed text from Paul regarding cross Support Provider policy "We understand that there might be some confusion regarding the Zowe bundles offered by different vendors. We would like to clarify that these bundles are not different versions of Zowe; rather, they include the open-source Zowe framework along with additional utilities provided by the respective vendors. Zowe itself remains consistent across these offerings, ensuring a standardized experience regardless of the bundle you choose. These utilities are designed to complement Zowe's capabilities and provide enhanced functionalities, but they do not alter the core Zowe framework. Rest assured, no matter which bundle you select, you will be working with the same version of Zowe. If you have any further questions or concerns, please do not hesitate to reach out to our support teams."

— Reply to this email directly, view it on GitHub https://github.com/zowe/community/issues/1972#issuecomment-1697632931, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJHZFLAUOT72QDJ73WD3223XXYAZLANCNFSM6AAAAAAX3LKJP4 . You are receiving this because you were assigned.Message ID: @.***>

-- Michael DuBois Senior Manager, Product Management - Mainframe Division Open Mainframe | Brightside | Zowe

Register today for the 2023 Mainframe Technical Exchanges! https://mainframe.broadcom.com/mainframe_technical_exchange

Broadcom Software 100 Baylis Road Melville, NY 11747 Office: +1 631 533 8048 | Mobile: +1 631 521 4609 @.***

-- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.

[jmertic]

I would agree @pdubz3 - this needs to be simple and clear. From how I've seen other projects approach similar cases, the discussion is more marketing than technical oriented, as the goal is to explain how an end-user should look at things.

I could see a simple visual outlining the stack, and then speaking to the key points a user should think about would help immensely. Something like a single Zowe box at the bottom, and then points above for Zowe Conformance solutions and end-user-built integrations and applications; the Zowe box could hit the key points of single instance, support through any Zowe Conformant Support Provider, official binaries at zowe.org, and Zowe Conforment solutions could illustrate why a user should care about that and how to ensure the vendors solutions are conformant.

[pdubz3]

As far as Paul's suggestion about a consistent response, I would suggest a few modiciations ... "We understand that there might be some confusion regarding the content of Zowe bundles offered by different vendors. We would like to clarify that the Zowe community and all of the Zowe-conformant support providers strongly agree that any distribution of Zowe offered by any vendor should contain genuine Zowe content equivalent to what you might acquire from www.zowe.org. Vendor distributions of Zowe may be supplemented to include additional value, but the Zowe content of such distributions must always remain genuine and should never vary from vendor to vendor. This is necessary to ensure a standardized experience for Zowe consumers regardless of the source of distribution, and so that vendor offerings which leverage Zowe can function seemlessly with any existing instance of Zowe. If you have any further questions or concerns, please do not hesitate to reach out to our support teams."

[balhar-jakub]

The Support provider policy looks good.

We should also talk about the topic on the quarterly webinar and I think we need to show more about how you use core Zowe with multiple extensions coming from different sources. This could be also a part of a blog post that can then be referenced from Zowe docs or zowe.org

• To support this we may need to figure out where and how we actually install the extensions for Zowe.

It would also be good to use the icon alongside "With Real Zowe inside" to claim that this Zowe will be supported by all the conformant support providers.

And on technical level, can we figure out a way to allow the vendors to test that the extensions work not just with Zowe but also together?

• And I do realize that the last may be an issue from the competition point of view.

[jmertic]

And on technical level, can we figure out a way to allow the vendors to test that the extensions work not just with Zowe but also together?

And I do realize that the last may be an issue from the competition point of view.

If the vendors would want to organize this separately, they could, but this is not something the Zowe project itself can mandate.

From a technical perspective, are there reasons why one could see two extensions not working together? Potential namespace collisions or similar bits I would think should be dealt with in the Conformance program or the integration points, but I'm not super familiar with the details.

[PWFlyMan]

Packing is an interesting topic: In many ways I like the fact that Broadcom/IBM/Rocket bundle to make life easier for their customers but it does subtly contribute to the thinking that there are differences. On balance perhaps the Zowe Charter is amended to discourage/bar any bundling. This would reduce the need for other measures (although some would be good anyway) and simplify the whole debate about versions. Would vendors accept the change and support this?

[pdubz3]

I would be opposed to any attempt by Zowe to "ban" what vendors can do. But I assume you're really talking about adding an additional requirement to the support conformance program that would prohibit bundling of solutions by vendors who seek a conformance badge. I would still be opposed to that, fundamentally because in spite of perception, you're asking vendors to make it harder for customers to consume, not easier. I still believe the solution to this is going to include a combination of education, communication, and making it as easy as possible for Zowe consumers to recognize genuine Zowe when they see it.

On Wed, Aug 30, 2023 at 8:46 AM Paul Wade @.***> wrote:

Packing is an interesting topic: In many ways I like the fact that Broadcom/IBM/Rocket bundle to make life easier for their customers but it does subtly contribute to the thinking that there are differences. On balance perhaps the Zowe Charter is amended to discourage/bar any bundling. This would reduce the need for other measures (although some would be good anyway) and simplify the whole debate about versions. Would vendors accept the change and support this?

— Reply to this email directly, view it on GitHub https://github.com/zowe/community/issues/1972#issuecomment-1699104072, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJHZFLEHGLGKRW4MGW3FWLDXX4Y3VANCNFSM6AAAAAAX3LKJP4 . You are receiving this because you were mentioned.Message ID: @.***>

-- Michael DuBois Senior Manager, Product Management - Mainframe Division Open Mainframe | Brightside | Zowe

Register today for the 2023 Mainframe Technical Exchanges! https://mainframe.broadcom.com/mainframe_technical_exchange

Broadcom Software 100 Baylis Road Melville, NY 11747 Office: +1 631 533 8048 | Mobile: +1 631 521 4609 @.***

-- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.

[jmertic]

One thing to be cognizant of is that you cannot put restrictions on business processes; otherwise, there could be questions regarding antitrust. The program must be focused on technical requirements.

[armstro]

I am not ignoring the discussion – just not had time to type up my notes from ZAC call or reply. I will before the week is out. I have asked Paul to have a github id so he can track the exchange. I assume we need Rose too.

Bear with me – my day job is getting in the way.

Bruce Armstrong IBM Z Principal Product Manager assigned to zowe.orghttps://www.openmainframeproject.org/projects/zowe 4205 S MIAMI BLVD, DURHAM NC 27703-9141 Email: @.**@.> Cell: 919-931-3132

From: John Mertic @.> Sent: Wednesday, August 30, 2023 8:59 AM To: zowe/community @.> Cc: Bruce Armstrong @.>; Assign @.> Subject: [EXTERNAL] Re: [zowe/community] Draft policies for handling of support issues by Zowe Support Providers (Issue #1972)

One thing to be cognizant of is that you cannot put restrictions on business processes; otherwise, there could be questions regarding antitrust. The program must be focused on technical requirements. — Reply to this email directly, view ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. Report Suspicious https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!2a-oiVaV6VPxUY4Tc0ptB_rywHBxQ3Dss_oY-ClKYzthq10nKN_W3rZ9qxVhYHDmQZLRXU_BQR6Ekf5tHtqFboTGsBluiij3sRE$ ‌ ZjQcmQRYFpfptBannerEnd

One thing to be cognizant of is that you cannot put restrictions on business processes; otherwise, there could be questions regarding antitrust. The program must be focused on technical requirements.

— Reply to this email directly, view it on GitHubhttps://github.com/zowe/community/issues/1972#issuecomment-1699121295, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AI6ZRGZHX3CASO4D7OJAABTXX42HVANCNFSM6AAAAAAX3LKJP4. You are receiving this because you were assigned.Message ID: @.**@.>>

[armstro]

Let me try to summarize what we discussed at the ZAC on 8/29 - apologies I am trying to make sense of my notes and it has been a few days. I think we agreeed clarifying the confusion is to be a phased approach

1st phase that hopefully is quick to implement

• Improve messaging on zowe.org someplace prominite - it is not obvious we have a Support Provider Conformance Program or the requirements of participation https://www.zowe.org/support - criteria is here https://openmainframeproject.org/wp-content/uploads/sites/14/2023/01/Zowe.Support.Provider.-.Test_.Evaluation.Guide_.Table_.pdf

• Once zowe.org is enhanced - ask the vendors in the Zowe Support Conformance Program to also improving messaging from their respecitve companies (either echo the criteria or link to the zowe.org info) . I think it would be a big help if any of our vendor presentations not only acknowledge the Zowe trademark but also include something like: "Vendor distributions of Zowe may be supplemented to include additional value, but the Zowe content of such distributions must always remain genuine and should never vary from vendor to vendor. "

2nd phase is a bit harder and may require development/innovation. We said that customers don't read websites or vendor support pages and we need a badge, message or "splash screen" that somehow indicates "authentic Zowe in use"? I think there are two challenges 1) what do we do by component since the components are different in how they display info (log message, badge, pop up, etc.) 2) Do we do something that can't be forged? Meaning if we say authentic Zowe how to we test for that? For example while I am a fan of the fingerprint app I am not sure it is practical to run at each startup and I assume it has limitations.

3rd phase is even harder (and less defined) - what I wrote down is something to the effect "who to call" but we did not discuss how (if) this is even feasible. Do we ask Conformance criteria to provide some log for an extension?

Additional comments:

• We agree it needs to be simple and clear - yet to document this will be complicated - any document we produce will soon be out of date - I think we need some innovation - we can't be the only open source community dealing with this.
• John I don't think "vendors to test that the extensions work not just with Zowe but also together?"....z/OS (and Zowe Conformance) are designed to allow coexistance without conflict. Vendors do not spend time on coexisting testing - they are more inclined to want to do complettitive displacement.

I will not be at the Sept 5th ZAC - hopefully some of the above comments are actionable ideas.

[PWFlyMan]

As far as Paul's suggestion about a consistent response, I would suggest a few modifications... "We understand that there might be some confusion regarding the content of Zowe bundles offered by different vendors. We would like to clarify that the Zowe community and all of the Zowe-conformant support providers strongly agree that any distribution of Zowe offered by any vendor should contain genuine Zowe content equivalent to what you might acquire from www.zowe.org. Vendor distributions of Zowe may be supplemented to include additional value, but the Zowe content of such distributions must always remain genuine and should never vary from vendor to vendor. This is necessary to ensure a standardized experience for Zowe consumers regardless of the source of distribution, and so that vendor offerings which leverage Zowe can function seamlessly with any existing instance of Zowe. If you have any further questions or concerns, please do not hesitate to reach out to our support teams."

I suggest discussing this in the ZAC today, can we agree on text and placement as a recommendation.

[RASakach]

This thread is very long and seems to be branching. Let's consider having someone draft the following:

• Describe the problem-to-solve
• Insert a proposal associated with the problem-to-solve
• Obtain volunteers to execute on the proposal

(to-be determine on the 9/12 ZAC call)

[PWFlyMan]

Notwithstanding support policies that I'm sure need to be discussed and improved I think we should go back to the original issue and solve first.

Problem: Avoid any perception that there are or might be different versions of Zowe. Proposal: Ask vendors to add a standard and recommended paragraph to all pages that include downloads (that include Zowe). The purpose being to assure customers (or anyone who downloads the package) that Zowe is the same as they would get from Zowe.org. Proposed Text: The Zowe content contained in this download is equivalent to what you might acquire from www.zowe.org. Vendor distributions of Zowe may be supplemented to include additional value, but the Zowe content of such distributions contain genuine Zowe that does not vary from vendor to vendor. If you have any further questions or concerns, please do not hesitate to reach out to our support teams.

[balhar-jakub]

Regardless of the things above I am working on an article exploring the Zowe distributions, the role of support providers, what Core/Extension means and how is it linked to Support.

[armstro]

Thanks @balhar-jakub - I ask that we (the Support Providers) be able to review the article before published - are you thinking of using Medium or the zowe.org site? I am pretty sure there are vendor specific considerations to Support. I understand you are speaking from the community view but I'd like to have some points made that allow we the vendors to publish our own article and link back to your article.

[jmertic]

@armstro I actually think it would be better to come right from the TSC versus having the support providers review/modify the content, for two main reasons...

1) This a program defined by the TSC itself, and not by the support providers participating in the program, and 2) Being a Zowe program, the support providers jumping in and defining things gets in the area of antitrust.

[armstro]

I am not talking about defining things for the community ..... I am talking about vendors knowing what is to be said to be able to position our Support offerings.....also to suggest points that should be made for the community ............. I don't think TSC defined Support Conformance - it was ZLC

[jmertic]

Hey @armstro - that makes sense; as long as the desire is awareness and a method for providing feedback that is perfectly fine. Where one gets into a gray area is when vendors drive the blog post.

[balhar-jakub]

@armstro I intend to publish it to medium.com/zowe and I will be looking to go through the regular review process and will be looking for feedback.

[armstro]

Thanks @balhar-jakub - do you happen to know who are the reviewers? I think @Joe-Winchester is one but I also know he's going to be out the next couple weeks. I assume you are looking to publish in that time frame?

[pdubz3]

I think most of the drafts for the Zowe publication are reviewed by me and Joe, but Mae can tell you what the process is when one of us is unavailable for a while.