| Code | | | |
| CD10 | The project produces Open Source software for distribution to the public, at no charge. | Yes. The project source code is licensed under the Apache License 2.0. | |
| CD20 | Anyone can easily discover and access the project's code. | Yes. The official website includes GitHub link which can access the project's repository on GitHub directly. | |
| CD30 | Anyone using standard, widely-available tools, can build the code in a reproducible way. | Yes. Our webpage and github repo provide "Getting Started" and several examples to allow users build our system. | |
| CD40 | The full history of the project's code is available via a source code control system, in a way that allows anyone to recreate any released version. | Yes. We use git and anyone can view the full history of the project via commit logs and tags of the releases. | |
| CD50 | The source code control system establishes the provenance of each line of code in a reliable way, based on strong authentication of the committer. When third parties contribute code, commit messages provide reliable information about the code provenance. | Yes. The project uses GitHub and managed by Apache Infra and ensures provenance of each line of code to a committer. Third-party contributions are accepted in accordance with the contributing guides. | |
| Licenses and Copyright | | | |
| LC10 | The Apache License, version 2.0, covers the released code. | Yes. All source files are licensed with Apache License v2.0. LICENSE can be found in the GitHub repository. | |
| LC20 | Libraries that are mandatory dependencies of the project's code do not create more restrictions than the Apache License does. | Yes. None of the dependencies create more restrictions. | |
| LC30 | The libraries mentioned in LC20 are available as Open Source software. | Yes. All libraries are open source. | |
| LC40 | Committers are bound by an Individual Contributor Agreement (the "Apache iCLA") that defines which code they may commit and how they need to identify code that is not their own. | Yes. All committers have iCLAs. | |
| LC50 | The project clearly defines and documents the copyright ownership of everything that the project produces. | Yes. All source files are with APLv2 header | |
| Releases | | | |
| RE10 | Releases consist of source code, distributed using standard and open archive formats that are expected to stay readable in the long term. | Yes. Source release is distributed via dist.apache.org and linked from download page. | |
| RE20 | The project's PPMC (Project Management Committee, see CS10) approves each software release in order to make the release an act of the Foundation. | Yes. All releases have been voted at dev@wayang.apache.org and general@incubator.apache.org, and have at least 3 PPMC member's votes. | |
| RE30 | Releases are signed and/or distributed along with digests that anyone can reliably use to validate the downloaded archives. | Yes. All releases are signed, and the KEYS are available. | |
| RE40 | The project can distribute convenience binaries alongside source code, but they are not Apache Releases, they are provided with no guarantee. | Yes. Users can easily build binaries from source code. We do not provide binaries as Apache Releases. | |
| RE50 | The project documents a repeatable release process so that someone new to the project can independently generate the complete set of artifacts required for a release. | Yes. Newcomers can follow our very detailed Release guide to make a new Apache Wayang release, and so far we had 3 different release managers. | |
| Quality | | | |
| QU10 | The project is open and honest about the quality of its code. Various levels of quality and maturity for various modules are natural and acceptable as long as they are clearly communicated. | Yes. The project records all bugs using Github Issues. | |
| QU20 | The project puts a very high priority on producing secure software. | Yes. All security issues will be addressed within 3 days. | |
| QU30 | The project provides a well-documented, secure and private channel to report security issues, along with a documented way of responding to them. | Yes. https://wayang.apache.org/docs/community/security | |
| QU40 | The project puts a high priority on backwards compatibility and aims to document any incompatible changes and provide tools and documentation to help users transition to new features. | Yes. Each release contains a “New features” on the website containing the release notes. The project aims to make no backward incompatible changes within a given major version. | |
| QU50 | The project strives to respond to documented bug reports in a timely manner. | Yes. The community has very small response times to issues and pull requests | |
| Community | | | |
| CO10 | The project has a well-known homepage that points to all the information required to operate according to this maturity model. | Yes. The official website includes all information users need to run Apache Wayang. | |
| CO20 | The community welcomes contributions from anyone who acts in good faith and in a respectful manner, and who adds value to the project. | Yes. The contributing guide provides information for anyone to contribute. | |
| CO30 | Contributions include source code, documentation, constructive bug reports, constructive discussions, marketing and generally anything that adds value to the project. | Yes. All good contributions including code and non-code are welcomed. | |
| CO40 | The community strives to be meritocratic and gives more rights and responsibilities to contributors who, over time, add value to the project. | Yes. The community has elected 3 new PPMC members/Committers the last year. | |
| CO50 | The project documents how contributors can earn more rights such as commit access or decision power, and applies these principles consistently. | Yes. The website has a clear guide on how to become a committer https://wayang.apache.org/docs/community/committer | |
| CO60 | The community operates based on consensus of its members (see CS10) who have decision power. Dictators, benevolent or not, are not welcome in Apache projects. | Yes. All decisions are made after voting by community members. | |
| CO70 | The project strives to answer user questions in a timely manner. | Yes. Our community answers user questions in a timely manner. | |
| Consensus | | | |
| CS10 | The project maintains a public list of its contributors who have decision power. The project's PPMC (Project Management Committee) consists of those contributors. | Yes. See Team with all PPMC members/committers and contributors. | |
| CS20 | Decisions require a consensus among PPMC members and are documented on the project's main communications channel. The PPMC takes community opinions into account, but the PPMC has the final word. | Yes. All decisions are made by votes on dev@wayang.apache.org, and with at least 3 +1 votes from PPMC. | |
| CS30 | The project uses documented voting rules to build consensus when discussion is not sufficient. | Yes. The project uses the standard ASF voting rules. | |
| CS40 | In Apache projects, vetoes are only valid for code commits. The person exercising the veto must justify it with a technical explanation, as per the Apache voting rules defined in CS30. | Yes. Apache Wayang community has not used the veto power yet except for code commits. | |
| CS50 | All "important" discussions happen asynchronously in written form on the project's main communications channel. Offline, face-to-face or private discussions that affect the project are also documented on that channel. | Yes. All important discussions and conclusions are sent to the dev list | |
| Independence | | | |
| IN10 | The project is independent from any corporate or organizational influence. | Yes. The PPMC members of Apache Wayang are from several organizations. | |
| IN20 | Contributors act as themselves, not as representatives of a corporation or organization. | Yes. The contributors act on their own initiative without representing a corporation or organization. | |