Chances

遵循以下最佳实践的项目将能够自愿的自我认证，并显示他们已经实现了核心基础设施计划（OpenSSF）徽章。

没有一套可以保证软件永远不会有缺陷或漏洞的做法；如果规范或假设是错误的，即使合适的方法也可能失败。也没有哪些做法可以保证一个项目能够维持健康和运作良好的开发者社区。但是，遵循最佳做法可以帮助改善项目的成果。例如，一些做法可以在发布之前进行多人评估，这可以帮助您找到其他难以找到的技术漏洞，并帮助建立信任，并希望不同公司的开发人员之间进行重复的交互。要获得徽章，必须满足所有“必须”和“禁止”的条款，满足所有“应该”条款或有合适的理由，和所有“建议”条款必须满足或未满足（至少希望考虑）。欢迎通过 GitHub网站创建问题或提出请求进行反馈。另外还有一个一般讨论邮件列表。

如果这是您的项目，请在您的项目页面上显示您的徽章状态！徽章状态如下所示： 项目15137的徽章级别为passing 这里是如何嵌入它：
您可以通过将其嵌入在您的Markdown文件中：
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/15137/badge)](https://www.bestpractices.dev/projects/15137)
或将其嵌入到HTML中来显示您的徽章状态：
<a href="https://www.bestpractices.dev/projects/15137"><img src="https://www.bestpractices.dev/projects/15137/badge"></a>


这些是通过级别条款。您还可以查看白银或黄金级别条款。

Baseline Series: 基准等级1 基准等级2 基准等级3

        

 基本 13/13 ●

  • 常规

    请注意，其他项目可能使用相同的名称。

    Scientific randomness from declared protocols, with verified arrays, explicit streams, execution receipts and conditional exact replay.

    请使用 SPDX许可证表达格式;例子包括“Apache-2.0”，“BSD-2-Clause”，“BSD-3-Clause”，“GPL-2.0+”，“LGPL-3.0 +”，“MIT”和“(BSD-2-Clause OR Ruby)”。
    如果有多种语言，请将它们列为逗号分隔值（可选空格），并将它们从最多到最少使用。如果有长列表，请至少列出前三个最常见的列表。如果没有语言（例如，这是仅文档或仅测试项目），请使用单个字符“ - ”。请使用每种语言的常规大小写，例如“JavaScript”。
    通用平台枚举（CPE）是用于信息技术系统，软件和软件包的结构化命名方案。在报告漏洞时，它可用于多个系统和数据库。

    Passing is earned. Silver proposals are grounded in merged source and execution evidence at https://github.com/autonomio/chances/blob/066fe51e4762d2be1b282fff115ec1784e6a3cfd/.bestpractices.json . PR #48 prepares authenticated source/distribution publication. Silver remains unearned: dependency findings, completed signed publication, access continuity, vulnerability-report credit, and the historical regression-test denominator remain unresolved. https://github.com/autonomio/chances/pull/48

  • 基本项目网站内容


    足够获得徽章！

    项目网站必须简明扼要地描述软件的作用（它解决了什么问题？）。 [description_good]
    必须采用潜在用户可以理解的语言（例如，它使用最少的术语/行话）。

    The README describes scientific randomness from declared protocols, checked arrays, execution receipts, and conditional replay. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/README.md


    足够获得徽章！

    项目网站必须提供有关如何获取和提供反馈（错误报告或增强功能）以及如何贡献的信息。 [interact]

    The README provides installation and first-use examples, the GitHub issue tracker, contributor setup, and license routes. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/README.md


    足够获得徽章！

    关于如何贡献的信息必须解释贡献流程（例如，是否使用拉请求？） (需要网址) [contribution]
    除非另有说明，否则我们假定 GitHub上的项目使用问题列表（Issues）和拉（Pull）请求。这些信息可以简短，例如，说明项目使用拉请求，问题跟踪器或邮寄到邮件列表中的哪一个。

    CONTRIBUTING links the constitution, locked development setup, meaningful review brief, and required quality checks. The constitution defines PR acceptance, coding conventions, and the ten merge gates. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/CONTRIBUTING.md https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/CLAUDE.md


    足够获得徽章！

    关于如何贡献的信息应包括对可接受的贡献的要求（例如，引用任何所需的编码标准）。 (需要网址) [contribution_requirements]

    CONTRIBUTING links the constitution, locked development setup, meaningful review brief, and required quality checks. The constitution defines PR acceptance, coding conventions, and the ten merge gates. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/CONTRIBUTING.md https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/CLAUDE.md


  • FLOSS许可证


    足够获得徽章！

    项目生产的软件必须作为FLOSS发布。 [floss_license]
    FLOSS是以符合开源定义或免费软件定义。此类许可证的示例包括 CC0 ， MIT ， BSD 2条款， BSD 3条款修订版， Apache 2.0 ， Lesser GNU通用公共许可证（LGPL），以及 GNU通用公共许可证（GPL）。为了我们的目的，这意味着许可证必须是：该软件也可以用其他许可证（例如，“GPLv2或专有”是可以接受的）。

    Chances is distributed under the OSI-approved MIT license at the repository root; third-party scaffold MIT notices are retained in their source locations. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/LICENSE https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/THIRD_PARTY.md


    足够获得徽章！

    建议由项目生成的软件的任何必需的许可证是由开放源码促进会（OSI）批准的许可证（英文）。 [floss_license_osi]
    OSI （开放源代码促进会）使用严格的审批流程来确定哪些许可证是开源软件（OSS）。

    Chances is distributed under the OSI-approved MIT license at the repository root; third-party scaffold MIT notices are retained in their source locations. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/LICENSE https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/THIRD_PARTY.md


    足够获得徽章！

    项目必须将其许可证在其源代码存储库中的标准位置发布。 (需要网址) [license_location]
    一种约定是将许可证发布为名为LICENSE或COPYING的顶级文件，其后可以带有扩展名，例如“ .txt”或“ .md”。另一种约定是使用一个名为LICENSES的目录，其中包含许可证文件。这些文件通常被命名为其SPDX许可证标识符，后跟适当的文件扩展名，如REUSE Specification中所述。请注意，此标准只是源存储库上的要求。从源代码生成某些内容（例如可执行文件，程序包或容器）时，无需包括许可证文件。例如，在为综合R存档网络（CRAN）生成R软件包时，请遵循标准CRAN惯例：如果许可证是标准许可证，请使用标准简短许可证规范（以避免安装另一文本副本）并列出排除文件（例如.Rbuildignore）中的LICENSE文件。同样，在创建Debian软件包时，您可以在版权文件中放置一个指向/ usr / share / common-licenses中的许可证文本的链接，并从创建的软件包中排除许可证文件（例如，通过在调用dh_auto_install之后删除文件） ）。我们鼓励在可行的情况下以生成的格式包含机器可读的许可证信息。

    Chances is distributed under the OSI-approved MIT license at the repository root; third-party scaffold MIT notices are retained in their source locations. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/LICENSE https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/THIRD_PARTY.md


  • 文档


    足够获得徽章！

    项目必须为项目生成的软件提供基本文档。 [documentation_basics]
    该文档必须在某些媒体（例如文本或视频）中，包括：如何安装它，如何启动它，如何使用它（可能使用教程使用示例）以及如何安全地使用它（例如，做什么和不做什么），如果这是软件的一个适当的话题。安全文档不需要太长篇幅。项目可以使用非项目内容的超文本链接作为文档。如果项目不生产软件，请选择“不适用”（N/A）。

    The README and maintained manual explain installation, declared operation/seed/stream inputs, array and receipt output, saved bundles, verification, replay, and migration. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/README.md https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/docs/README.md


    足够获得徽章！

    项目必须提供描述项目生成的软件的外部接口（输入和输出）的参考文档。 [documentation_interface]
    外部接口的文档向最终用户或开发人员解释如何使用它。这将包括其应用程序接口（API），如果软件有。如果它是一个库，记录可以调用的主要类/类型和方法/函数。如果是Web应用程序，定义其URL接口（通常是其REST接口）。如果是命令行界面，请记录其支持的参数和选项。在许多情况下，最好是自动生成大部分文档，以便本文档随着软件的更改而保持同步，但这并不是必需的。项目可以使用非项目材料的超文本链接作为文档。文档可以自动生成（实际上这通常是最好的方法）。可以使用Swagger / OpenAPI生成REST接口的文档。代码界面文档可以使用 JSDoc （JavaScript）， ESDoc （JavaScript），pydoc（Python）和Doxygen（很多）。仅在实现代码中添加注释不足以满足本条款；在没有阅读所有源代码的情况下，需要一个简单的方法来查看信息。如果项目不生产软件，请选择“不适用”（N/A）。

    Reference documentation defines Python and CLI interfaces, parameter contracts, catalog entries, returned values, structured failures, receipt fields, and compatibility limits. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/docs/Reference/README.md https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/docs/Reference/Specifications-and-Receipts.md


  • 其他


    足够获得徽章！

    项目网站（网站，存储库和下载URL）必须使用TLS支持HTTPS。 [sites_https]
    您可以从Let's Encrypt获取免费证书。项目可以使用（例如） GitHub页面实现此条款， GitLab页面，或 SourceForge项目页面。如果您使用具有自定义域的GitHub页面，则可以使用内容传送网络（CDN）作为代理来支持HTTPS，例如博客文章“使用CloudFlare安全加速GitHub页面”，以满足此条款。如果您支持HTTP，我们敦促您将HTTP流量重定向到HTTPS。

    The project homepage and repository are served at https://github.com/autonomio/chances and package downloads at https://pypi.org/project/chances/. The configured documentation target is not claimed to be a deployed website.


    足够获得徽章！

    该项目必须有一个或多个讨论机制（包括建议的更改和问题），可搜索，允许通过URL访问消息和主题，使新人能够参与一些讨论，并且不需要客户端安装专有软件。 [discussion]
    可接受机制的示例包括归档邮件列表，GitHub问题和拉请求讨论，Bugzilla，Mantis和Trac。如果满足这些标准，异步讨论机制（如IRC）是可以接受的；确保有一个URL可访问归档机制。允许专有JavaScript，但不鼓励。

    Public GitHub issues and pull requests provide searchable URL-addressable discussions and report history, open to new participants through a web browser. https://github.com/autonomio/chances/issues https://github.com/autonomio/chances/pulls


    足够获得徽章！

    项目应该提供英文文档，并能够接受英文的代码的错误报告和评论。 [english]
    英语是计算机技术的通用语言；支持英语增加了全球不同潜在开发者和检视者的数量。即使核心开发人员的主要语言不是英文，项目也可以达到这个标准。

    Maintained README, guides, references, developer instructions, issue forms, and contribution process are written in English. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/README.md https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/CONTRIBUTING.md


    足够获得徽章！

    必须维护该项目。 [maintained]
    至少，项目应尝试响应重大问题和漏洞报告。可能正在维护一个积极追求徽章的项目。所有项目和人员的资源都有限，典型项目必须拒绝某些提议的更改，因此有限的资源和提议拒绝本身并不表示未维护的项目。

    当项目知道将不再维护该项目时，应将此标准设置为“未满足”，并使用适当的机制向其他人指示该项目将不会得到维护。例如，使用“ DEPRECATED”作为其自述文件的第一个标题，在其主页开头附近添加“ DEPRECATED”，在其代码存储库项目说明的开头添加“ DEPRECATED”，在其中添加无需维护的标志其自述文件和/或主页，在任何软件包存储库中将其标记为已弃用（例如npm deprecate ），和/或使用代码存储库的标记系统对其进行归档（例如GitHub的“ archive”设置，GitLab的“ archived”标记， Gerrit的“只读”状态，或SourceForge的“已放弃”项目状态）。可以在这里找到更多讨论。

    The Chances 2.0 implementation, documentation and governance were reviewed and merged on 2026-10-01, and subsequent CI and dependency monitoring run on the protected master branch. https://github.com/autonomio/chances/pull/19 https://github.com/autonomio/chances/actions


 变更控制 9/9 ●

  • 公开的版本控制的源代码存储库


    足够获得徽章！

    该项目必须有一个版本控制的源代码存储库。它必须是公开可读的并可通过URL访问。 [repo_public]
    该URL可以与项目URL相同。该项目可能在特定情况下使用私人（非公开）分支，而更改不会公开发布（例如，在向公众披露漏洞之前修复漏洞）。

    The public Git repository records commit authors, timestamps, reviewed intermediate commits, issues, and pull requests between releases. https://github.com/autonomio/chances https://github.com/autonomio/chances/pull/19


    足够获得徽章！

    项目的源代码存储库必须跟踪所做的更改，谁进行了更改，何时进行了更改。 [repo_track]

    The public Git repository records commit authors, timestamps, reviewed intermediate commits, issues, and pull requests between releases. https://github.com/autonomio/chances https://github.com/autonomio/chances/pull/19


    足够获得徽章！

    为了实现协作检视，项目的源代码存储库必须包括临时版本，以便检视版本之间的变化；它不得仅包括最终版本。 [repo_interim]
    项目可以选择从其公共源代码库中删除特定的临时版本（例如，修复特定的未公开安全漏洞，可能永远不会公开发布的内容，或者包括不能合法发布而且不是最终版本的内容）。

    The public Git repository records commit authors, timestamps, reviewed intermediate commits, issues, and pull requests between releases. https://github.com/autonomio/chances https://github.com/autonomio/chances/pull/19


    足够获得徽章！

    建议使用通用分布式版本控制软件（例如，git）作为项目的源代码存储库。 [repo_distributed]
    Git不是必须，项目在合适场景可以使用集中版本控制软件（如subversion）。

    The public Git repository records commit authors, timestamps, reviewed intermediate commits, issues, and pull requests between releases. https://github.com/autonomio/chances https://github.com/autonomio/chances/pull/19


  • 唯一版本编号


    足够获得徽章！

    项目生成的用于每个用户使用的版本必须具有唯一版本标识符。 [version_unique]
    本条款可以通过各种方式来满足，包括提交ID（例如git提交ID或者Mercurial 更改列表id）或版本号（包括使用语义版本或基于日期的方案，如YYYYMMDD的版本号）。

    The project manifest supplies a unique semantic version; the required version gate checks strictly forward major/minor/patch changes against the protected base and matches the changelog. Release policy forbids reusing a tagged or uploaded version. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/pyproject.toml https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/docs/Developer/Release-Policy.md


    足够获得徽章！

    建议使用语义版本控制（SemVer）格式进行发布。 [version_semver]
    其他版本编号方案，如提交ID（例如git commit id或mercurial changeset id）或基于日期的方案，如YYYYMMDD，可以用作版本号，因为它们是唯一的。一些备选方案可能会导致问题，因为用户可能无法轻松确定是否是最新的。如果所有目标客户仅运行最新版本，则SemVer可能不太有助于识别软件版本（例如，它是通过持续交付不断更新的单个网站或互联网服务的代码）。

    勉强够获得徽章。

    建议项目识别其版本控制系统中的每个版本。例如，建议使用git的项目，使用git标签识别每个版本。 [version_tags]

    GitHub currently exposes only v0.1.9, while PyPI lists 0.1.1 and 0.1.3 through 0.1.9. Historical released versions are therefore not all identified by current Git tags. This SUGGESTED criterion is considered but not claimed Met; the merged release workflow will tag future releases. https://github.com/autonomio/chances/tags https://pypi.org/project/chances/#history https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/scripts/create_release.py


  • 发行说明


    足够获得徽章！

    该项目必须在每个版本中提供发布说明，这是该版本中主要变化的可读的摘要，以帮助用户确定是否应升级，升级影响将如何。发行说明不能是版本控制日志的原始输出（例如，“git log”命令结果不是发行说明）。其产出不适用于多个地点的项目（如单个网站或服务的软件），并采用持续交付，可以选择“N/A”。 (需要网址) [release_notes]
    发行说明可以以各种方式实施。许多项目将它们添加到名为“NEWS”，“CHANGELOG”或“ChangeLog”的文件中，可选的包含“.txt”，“.md”或“.html”等扩展名。历史上，术语“更改日志”是指每个更改的日志，但为了满足这些条款，需要的是可读取的摘要。发行说明可以由版本控制系统机制提供，例如 GitHub发布工作流程。

    Published release v0.1.9 has a human-authored summary. Current CHANGELOG documents the Chances 2.0 changes, and release creation requires the matching nonempty newest section. https://github.com/autonomio/chances/releases/tag/v0.1.9 https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/CHANGELOG.md https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/.github/workflows/pr_post_release.yml


    足够获得徽章！

    发行说明必须列出每个新版本中修复的每个公开的漏洞。如果没有发行说明或者没有公开的漏洞，选择“不适用”。 [release_notes_vulns]
    如果用户通常不能在自己的计算机上实际更新软件，而必须依靠中间人来执行升级（对于内核和与内核交织的底层软件通常是这种情况），项目可以选择“不适用”（N/A）。

    No publicly known Chances runtime vulnerability or CVE/GHSA fix was identified in the public records checked on 2026-10-01: OSV exact PyPI package and all eight published versions, GitHub repository and global advisories, NVD matches and published Git history. The criterion excludes dependencies. This does not assert absence of undiscovered or private vulnerabilities. https://github.com/autonomio/chances/security/advisories https://github.com/advisories?query=ecosystem%3Apip+chances https://osv.dev/list?q=chances https://github.com/autonomio/chances/commits/master/


 报告 8/8 ●

 质量 13/13 ●

 安全 16/16 ●

 分析 8/8 ●


您可以使用工具和AI系统通过简单的URL提交变更建议，例如 https://www.bestpractices.dev/zh-CN/projects/15137/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced。请参阅我们的自动化提案系统，了解具体操作方法。 该数据可在社区数据许可协议 – 许可性，版本 2.0 (CDLA-Permissive-2.0)下获取。这意味着数据接收方可以共享数据，无论是否经过修改，只要数据接收方在共享数据时提供本协议文本。请注明Mikko Kotila和OpenSSF最佳实践徽章贡献者。

项目徽章条目拥有者： Mikko Kotila.
最后更新于 2026-10-01 15:58:41 UTC, 最后更新于 2026-10-03 08:29:52 UTC。 最后在 2026-10-01 16:42:28 UTC 获得通过徽章。