Skip to content
Branch: master
Find file Copy path
Find file Copy path
4 contributors

Users who have contributed to this file

@jmertic @jhenryRocket @MarkAckert @liuxh0
144 lines (96 sloc) 9.3 KB

Zowe Community

This guide will help you navigate the Zowe community, and learn more on how to contribute and provide feedback.

Zowe Sub-projects

The Zowe community consists of several sub-projects that focus on specific areas of the codebase. Like any open source project, each sub-projects has it's own governance structure and release process that aligns with the primary framework guidelines.

Current Zowe Sub-projects are:

Zowe API Mediation layer

Gateway that acts as a reverse proxy for z/OS services, together with a catalog of REST APIs and a dynamic discovery capability. This project includes provides core services for working with MVS Data Sets, JES, as well as working with z/OSMF REST APIs and a framework for Single Sign On (SSO).

Zowe CLI

Command-line interface that lets you interact with the mainframe remotely and use common tools such as Integrated Development Environments (IDEs), shell commands, bash scripts, and build tools for mainframe development. It provides a set of utilities and services for application developers that want to become efficient in supporting and building z/OS applications quickly. The CLI provides a core set of commands for working with data sets, USS, JES, as well as issuing TSO and console commands.

Zowe App Framework

Web-based user interface (UI) that provides a virtual desktop containing a number of apps allowing access to z/OS functions through the Zowe API Mediation layer. This project includes includes apps such as a 3270 terminal and a VT Terminal, as well as an editor and explorers for working with JES, MVS Data Sets and Unix System Services.

Zowe Community Teams

Zowe has a number of cross-functional teams to support the common functions across the subprojects.


Maintains the Zowe documentation.


Spends time in the various community communication channels helping users and those looking to build on top of Zowe.

Zowe Foundation

Maintains the Zowe installation tools and integration of Zowe components.

Communication Channels

All community activities are scheduled on the Zowe Community calendar. All meetings are an open invitation for any community member to join.

You can also engage fellow community members through these channels


The Zowe community uses Slack as the primary means of interacting to facilitate active collaboration through the following channels.

Register an account with Slack at

  • #zowe-user - This channel is for users to ask questions, look for help and interact with each other.
  • #zowe-dev - Zowe development discussions.
  • #zowe-doc - Discuss or ask questions about the documentation.
  • #zowe-onboarding - Develop the material and supporting activities for onboarding developers and users.
  • #zowe-zlc - Ask questions or discuss topics with the Zowe Leadership Committee.

Sub-project specific channels:

  • #zowe-api - Ask questions about the API Mediation Layer, propose new ideas, or interact with the squad.
  • #zowe-build - Discuss and review build related Issues.
  • #zowe-cli - Ask questions about Zowe CLI, propose new ideas, and interact with the Zowe CLI community.
  • #zowe-core - Expand upon the base technologies being contributed to the project.

Mailing Lists

Community Forums

Look for discussion on Zowe topics on the Open Mainframe Project Community Forums.


All code in Zowe aligns with the establshed licensing and copyright notice guidelines

Submit an issue

You can submit an issue (Bug or Feature) on Zowe in general at If you have an issue that is specific to a sub-project or community team, feel free to submit an issue against a specific repo.

Pull Request Guidelines

Pull requests cannot be merged without the approval of at least one maintainer, who will be looking for the pull request to meet requirements as follows:

  • The code in the pull request must adhere to the general Code Style Guidelines and those for the sub-project.
  • The code must compile/transpile (where applicable) and pass a smoke test such that the code is not known to break the current state of Zowe.
  • The pull request must describe the purpose and implementation to the extent that the maintainer understands what is being accomplished. Some pull requests need less details than others depending on novelty.
  • The pull request must state how to test this change, if applicable, such that the maintainer or a QA team can check correctness. The explanation may simply be to run included test code.
  • If a pull request depends upon a pull request from the same / another repository that is pending, this must be stated such that maintainers know in which order to merge open pull requests.

Reporting Security Issues

Please direct all security issues to A member of the security team will reply to acknowledge receipt of the vulnerability and coordinate remediation with the affected project.

You can’t perform that action at this time.