1. Code and Document Code and Document
OA-CD-10
[中] The project code is easy to find and can be publicly accessed.
【EN】The project's code is easily discoverable and publicly accessible.
OA-CD-20
[Medium] Commonly used standard tools can be used to re-build the project code.
【EN】The code can be built in a reproducible way using widely available standard tools.
OA-CD-30
[Medium] The complete change history of the project code should be retained through the source code management system, and all released versions can be rebuilt.
【EN】The full history of the project's code is available via a source code control system, in a way that allows any released version to be recreated.
OA-CD-40
[Medium] Each line of code must be established by a submitter with a strong authentication mechanism through the source code management system. When submitting a third-party contribution, the submission remarks must include reliable code source information.
【EN】The provenance of each line of code is established via the source code control system, in a reliable way based on strong authentication of the committer. When third-party contributions are committed, commit messages provide reliable information about the code provenance.
OA-CD-50
[Medium] The project must have end-user documents, such as: API, CLI, dashboard, installation and deployment, configuration, etc.
【EN】The project must have end-user docs in place such as API use, CLI use, Dashboard use, Deployment use, Configuration use.
OA-CD-60
[中] The project should have a verifiable history of user support, which can be a reply in the mailing list or issue system.
【EN】The project should have a proven history of providing user support,such as replies in mailing list or issue systems.
2. Process ( Process )
OA-PR-10
[中] The project needs to have a code submission process that conforms to industry best practices.
【EN】The project requires a code commit process that meets industry best practices.
OA-PR-20
[中] The project team should work with the marketing team to determine a suitable official name.
【EN】The project should have engaged with marketing team to check suitable official name.
OA-PR-30
[中] The project needs to pass an independent third-party security audit.
【EN】The project should have completed an independent and third party security audit.
OA-PR-40
[中] The project must use tasks, defects, and design tracking tools approved by the Foundation's infrastructure team.
【EN】The project must use task, defect and design track tools that approved by infrastructure team of OpenAtom Foundation.
3. Licenses and Copyright ( Licenses and Copyright )
OA-LC-10
[中] Code release needs to meet the compliance/compatibility requirements of the open source license used by the project, and comply with the intellectual property policy of the Open Atom Open Source Foundation.
【EN】The code is released under the open source license that project used, meets the compatibility requirements,and complies with OpenAtom Foundation's IPR policy.
4. release ( Releases )
OA-RE-10
[Medium] The source code must be included in the release, and a standard and open packaging format must be adopted for distribution to maintain readability for a long time.
【EN】Releases consist of source code, distributed using standard and open archive formats that are expected to stay readable in the long term.
OA-RE-20
[中] The release is approved by the project's project management committee.
【EN】Releases are approved by the project's PMC (Project Management Committee).
OA-RE-30
[Medium] The release needs to be digitally signed or with a hash digest to verify the integrity and reliability of the downloaded package.
【EN】Releases are signed and/or distributed along with digests that can be reliably used to validate the downloaded archives.
OA-RE-40
[中] The release must include source code, and binary files can also be released at the same time.
【EN】Release must include source code; convenience binaries can be distributed alongside source code.
OA-RE-50
[Medium] The release process must have detailed documentation and be repeatable. According to the document guidelines, anyone can independently generate all the products required for release.
【EN】The release process is documented and repeatable to the extent that anyone is able to independently generate the complete set of artifacts required for a release.
OA-RE-60
[中] The project must have a clear version plan, and at least 2 regular follow-up milestones must be established.
【EN】The project must have a clear roadmap and must have followed at least two common milestones.
5. Quality ( Quality )
OA-QU-10
[中] The project should be open and honest about the quality of the code.
【EN】The project is open and honest about the quality of its code.
OA-QU-20
[中] The safety of the project is the highest priority.
【EN】The project puts a very high priority on secure software.
OA-QU-30
[Medium] A set of standardized security response procedures need to be provided.
【EN】The project requires a standardized security response process.
OA-QU-40
[Medium] The project should pay attention to compatible historical versions, document all incompatible changes as much as possible, and provide tools and instructions to help users transition to new features.
【EN】The project puts a high priority on backwards compatibility, aims to document any incompatible changes and provides tools and documentation to help users transition to new features.
OA-QU-50
[中] The project should strive to respond to the reported BUG in a timely manner.
【EN】The project strives to respond to documented bug reports in a timely manner.
OA-QU-60
[Middle] The project must have reasonable CI process/tools, unit testing and test code coverage.
【EN】The project must have decent CI process/tools, unit test and test code coverage.
OA-QU-70
[Middle] The project shall reasonably classify and grade the registered issues.
【EN】The project should have a decent record of triaging incoming issues.
6. Community ( Community )
OA-CO-10
[中] The project has a well-known homepage.
【EN】The project should have a well-known homepage.
OA-CO-20
[中] The community welcomes the contributions of all participants who are well-intentioned, respected, and add value to the project.
【EN】The community welcomes contributions from anyone who acts in good faith and in a respectful manner and adds value to the project.
OA-CO-30
[Medium] Contributions include, but are not limited to, source code, and can also be documents, constructive error reports, constructive discussions, marketing, or any other content that will add value to the project.
【EN】Contributions include not only source code, but also documentation, constructive bug reports, constructive discussions, marketing and generally anything that adds value to the project.
OA-CO-40
[中] The community must conform to the spirit of good governance. Over time, contributors who add value to the project will be given more rights and responsibilities.
【EN】The community strives to be meritocratic and over time aims to give more rights and responsibilities to contributors who add value to the project.
OA-CO-50
[中] The operation of the community is based on the consensus of members with decision-making power, and avoid talking about it.
【EN】The community operates based on consensus of its members who have decision power. Dictators, benevolent or not, are not welcome in projects.
OA-CO-60
[中] The project is committed to answering users’ questions in a timely manner.
【EN】The project strives to answer user questions in a timely manner.
OA-CO-70
[Medium] The project needs to display the incubation status of the project on the project website or Readme.
【EN】The project should list project’s incubation status prominently on website/readme.
OA-CO-80
[Medium] The project has a certain number of active committers and a considerable number of code submissions and merged numbers.
【EN】The project should have a healthy number of committers, and demonstrate a substantial ongoing flow of commits and merged contributions.
OA-CO-90
[中] The project should clearly define the project governance and the management process of the submitter.
【EN】The project should explicitly define a project governance and committer process.
OA-CO-100
[Medium] The project should at least provide a public user list in the main code repository (for example, provide ADOPTERS.md, or display the user's logo list on the project website).
【EN】The project should have a public list of project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the project website).
7. Consensus Building ( )
OA-CS-10
[Middle] The project maintains a public list of contributors with decision-making power-the project management committee is composed of these contributors.
【EN】The project maintains a public list of its contributors who have decision power -- the project's Project Management Committee consists of those contributors.
OA-CS-20
[Middle] Decisions are formed by the consensus of the members of the project governance committee and recorded in the main communication channel. The opinions of the community must be considered. If there are any objections, the project management committee has the final decision.
【EN】Decisions are made by consensus among Project Management Committee members and are documented on the project's main communications channel. Community opinions are taken into account but the Project Management Committee has the final word if needed.
OA-CS-30
[Medium] When consensus cannot be formed through discussion, documented voting rules can be used to achieve the goal. In the project, the veto is only valid for code submission, and the veto requires reasonable technical reasons.
【EN】Documented voting rules are used to build consensus when discussion is not sufficient. In projects, vetoes are only valid for code commits and are justified by a technical explanation.
OA-CS-40
[Middle] All important discussions should be conducted asynchronously on the main communication channel of the project in written form. Offline, face-to-face, or private discussions that will have an impact on the project should also be recorded in this channel.
【EN】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.
8. neutral ( Independence )
OA-IN-10
【中】The project is independent of any company or organization.
【EN】The project is independent of any company or organization.
OA-IN-20
[中] The project must have a core review team of no less than three parties.
【EN】The project must have a diverse core reviewers team (at least 3).
OA-IN-30
[中] The community role permissions of contributors should not be affected by changes in the employment relationship.
【EN】The role & permissions of contributors in the community should not be affected when their employment relationship changes.
OA-IN-40
[Middle] Project graduation requires nominations of at least three TOC members to enter the graduation process.
【EN】The project should require at least 3 TOC members to step forward as sponsors to enter graduation process.
9. Maturity ( Maturity )
OA-MA-10
[Medium] At least three independent users have successfully used the project in the production environment, and TOC judges whether the users are effective based on the quality and scope.
【EN】The project should be used successfully in production by at least 3 independent end users which, in the TOC‘s judgement, are of adequate quality and scope.
10. Others (Others)
OA-OT-10
[中] Project graduation requires 2/3 approval votes of all TOC seats.
【英】To enter graduation, the project should receive the affirmative vote of two-thirds of the authorized TOC.
OA-OT-20
[Medium] The above indicators have certain deviations due to the type, scope and size of the project, so the TOC has certain discretionary powers on the above indicators.
【EN】Since these metrics can vary significantly depending on the type, scope and size of a project, the TOC has final judgement over the level of activity that is adequate to meet these criteria.
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。