Astetik

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

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

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


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

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

        

 基本 0/5 ●

  • 常规

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

    Astetik compiles scientific figures, numerical output, and verifiable provenance from declared plot specifications and a centralized design manifest.

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

  • 先决条件


    不足以获得徽章。

    该项目必须拥有银级徽章。 [achieve_silver]

  • 项目监督


    不足以获得徽章。

    项目必须具有2个或更多的“公交车因子”。 (需要网址) [bus_factor]
    “公交车系数”（又名“卡车因子”）是指最少数量的项目成员，如果突然离开项目（“被公交车撞了”），项目会由于缺乏具备知识的或有能力的人员而暂停。 卡车因子 工具可以对GitHub上的项目进行估计。有关详细信息，请参阅Cosentino等人的评估Git存储库的卡车因子。

    Deep compiler knowledge is currently concentrated in the primary maintainer; administrator rights and a backup capable of restoring access do not demonstrate two project experts. The present small maintainer team uses published source, canonical developer documentation, retained regression evidence and a named operational continuation path to reduce interruption. This justified unmet SHOULD transparently preserves that actual staffing boundary. Evidence: https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/MAINTAINERS.md https://github.com/autonomio/astetik/blob/a296fbd7a09e55ca9f002caa4b6499defc74b638/MAINTAINERS.md


    未知的所需信息，不足以用于徽章。

    该项目必须至少有两个不相关的重要贡献者。 (需要网址) [contributors_unassociated]
    如果同一组织（作为雇员或承包商）支付工作费用，并且组织将从项目的结果中受益，则贡献者是相关联的。如果通过其他组织得到财务补助（例如，源自政府或非政府组织，支付给不同组织的科学补助金不会导致捐助者关联），不视为来自同一组织。重要贡献者定义为过去一年对项目做出了不平凡的贡献。一个重要贡献者的良好指标的例子是：编写至少1,000行代码，贡献50个提交或至少提交20页的文档。

  • 其他


    未知的所需信息，不足以用于徽章。

    项目必须在每个源文件中包含许可证声明。这可以通过在每个文件开头附近的注释中加入以下内容来实现： SPDX-License-Identifier: [SPDX license expression for project]。 [license_per_file]
    这可以通过在自然语言中包含许可证标识来完成。该项目还可以包括完整许可证文本，或者指向许可证文本的稳定URL。请注意，license_location条款要求项目许可证在标准位置。有关SPDX许可证表达式的更多信息，请参阅SPDX教程。请注意与 copyright_per_file 的关系，其内容通常在许可证信息之前。

 变更控制 1/4 ●

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


    足够获得徽章！

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

    The public Git repository retains attributable dated commits and interim review branches/PRs between tagged releases. Evidence: https://github.com/autonomio/astetik https://github.com/autonomio/astetik/commits/master https://github.com/autonomio/astetik/pull/62


    未知的所需信息，不足以用于徽章。

    该项目必须清楚地识别新的或临时贡献者可以执行的小型任务。 (需要网址) [small_tasks]
    此标识通常通过在项目使用的一个或多个标签的问题跟踪器中标记所选问题来完成，例如 up- for-grabs ，仅限第一时间，“小修复”，微任务或IdealFirstBug。这些新任务不需要添加功能；他们可以改进文档，添加测试用例或其他有助于项目的内容，并帮助贡献者更了解项目。

    未知的所需信息，不足以用于徽章。

    项目必须要求开发人员使用双因素身份验证（2FA）来更改中央存储库或访问敏感数据（如私密漏洞报告）。这种2FA机制可以使用没有密码学机制的方案，如SMS（短消息），尽管不推荐。 [require_2FA]

    未知的所需信息，不足以用于徽章。

    项目的双因素身份认证（2FA）应该使用加密机制来防止仿冒。基于短消息服务（SMS）的2FA本身不符合此标准，因为它不被加密。 [secure_2FA]
    满足此条款的2FA机制将是一种基于时间的一次性密码（TOTP）应用程序，可自动生成在一段时间后更改的验证码。请注意， GitHub支持TOTP 。

 质量 2/7 ●

  • 编码标准


    未知的所需信息，不足以用于徽章。

    该项目必须记录其代码检视需求，包括代码检视是如何进行的，必须检查的内容以及哪些是可接纳的内容。 (需要网址) [code_review_standards]
    另请参阅 two_person_review 和contribution_requirements 条款。

    未知的所需信息，不足以用于徽章。

    该项目必须至少有50％的修改（作者之外的人提出的）在发布之前审查，以确定是否是一个有价值的修改，并且没有已知的问题，会反对其包含 [two_person_review]

  • 可工作的构建系统


    未知的所需信息，不足以用于徽章。

    该项目必须具有可重复构建。如果没有发生构建（例如，直接使用源代码而不是编译的脚本语言），请选择“不适用”（N/A）。 (需要网址) [build_reproducible]
    可重复的构建意味着多方可以独立地重做从源文件生成信息的过程，并获得每比特完全相同的结果。在某些情况下，这可以通过强制某种排序来解决。 JavaScript开发人员可能会考虑使用npm shrinkwrap和webpack的OccurenceOrderPlugin。 GCC和clang用户可能会发现-frandom-seed选项有用。通常可以通过指定可用于重新构建的特定容器或虚拟机的加密散列来为外部方定义构建环境（包括工具集）。 可重复构建项目具有文档指导如何执行此操作。

  • 自动测试套件


    足够获得徽章！

    测试套件必须以该语言的标准方式进行调用。 (需要网址) [test_invocation]
    例如“make check”，“mvn test”或“rake test”。

    Public pytest suites are MIT-licensed project sources, standard python -m pytest invocations are documented, and merged PR62 test CI passed. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/CONTRIBUTING.md https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/tests https://github.com/autonomio/astetik/actions/runs/36914931313


    足够获得徽章！

    该项目必须实施持续集成，将新的或更改的代码经常集成到中央代码库中，并对结果进行自动化测试。 (需要网址) [test_continuous_integration]
    在大多数情况下，这意味着每个在项目上全职工作的开发人员至少每天都会整合。

    Required GitHub workflows run package tests, coverage, static analysis, governance and documentation on proposed PRs; source compatibility runs cover Python 3.11–3.13. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/.github/workflows/ci.yml https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/.github/workflows/pr_checks_tests.yml https://github.com/autonomio/astetik/pull/62


    未知的所需信息，不足以用于徽章。

    如果有至少一个FLOSS工具可以以所选语言度量此条款，该项目的FLOSS自动测试套件必须具有至少90％语句覆盖率。 [test_statement_coverage90]

    未知的所需信息，不足以用于徽章。

    如果有至少一个FLOSS工具可以以所选语言度量此条款，该项目的FLOSS自动测试套件必须具有至少80％分支覆盖率。 [test_branch_coverage80]

 安全 3/5 ●

 分析 2/2 ●


您可以使用工具和AI系统通过简单的URL提交变更建议，例如 https://www.bestpractices.dev/zh-CN/projects/15154/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-02 06:55:56 UTC, 最后更新于 2026-10-02 09:51:47 UTC。 最后在 2026-10-02 09:07:57 UTC 获得通过徽章。