BadgeApp

基本 3/17 ●

识别

项目的人类可读的名称是什么？
请注意，其他项目可能使用相同的名称。

什么是项目的简要描述？

OpenDaylight is a highly available, modular, extensible, scalable and multi-protocol controller infrastructure built for SDN deployments on modern heterogeneous multi-vendor networks. OpenDaylight provides a model-driven service abstraction platform that allows users to write apps that easily work across a wide variety of hardware and south-bound protocols.

项目的URL（作为一个整体）是什么？
https://www.opendaylight.org

版本控制存储库的URL是什么（它可能与项目URL相同）？
https://github.com/opendaylight
先决条件

Criterion [achieve_passing]
完成

不完整

项目必须拥有通过徽章。 ^{[achieve_passing]}

基本项目网站内容

完成

不完整

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

https://docs.opendaylight.org/en/latest/#contributing-to-opendaylight

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

    (b) The contribution is based upon previous work that, to the best
        of my knowledge, is covered under an appropriate open source
        license and I have the right under that license to submit that
        work with modifications, whether created in whole or in part
        by me, under the same open source license (unless I am
        permitted to submit under a different license), as indicated
        in the file; or

    (c) The contribution was provided directly to me by some other
        person who certified (a), (b) or (c) and I have not modified
        it.

    (d) I understand and agree that this project and the contribution
        are public and that a record of the contribution (including all
        personal information I submit with it, including my sign-off) is
        maintained indefinitely and may be redistributed consistent with
        this project or the open source license(s) involved.

项目监督

Criterion [dco]
完成

不完整

?

该项目应该有一个合法机制，所有对项目软件做出显著贡献的开发人员都声明他们有合法授权作出这些贡献。最常用且易于实施的方法是使用开发者原产地证书（DCO），用户可以在其提交中添加“signed-off-by”，另外，项目链接到DCO网站。本条款也可以使用贡献者许可协议（CLA）或其他法律机制实现。 (需要网址) ^[dco]
DCO是推荐的机制，因为它易于实现，在源代码中进行跟踪，并且git使用“commit -s”直接支持“签名”功能。更有效的是，项目文件解释了该项目的“签名”手段。 CLA是一项法律协议，用于定义知识产权许可给组织或项目的条款。捐助者转让协议（CAA）是将知识产权权利转让给另一方的法律协议；项目不必具备CAA，因为CAA增加了潜在贡献者不愿贡献的风险，特别是如果接收者是一个营利性组织。 Apache Software Foundation CLA（个人贡献者许可证和公司CLA）是CLA的示例，用于确定项目的这些CLA的风险对项目的影响小于其获益。

https://docs.opendaylight.org/en/stable-argon/contributor-guides/newcomers-guide.html#prepare-a-change : "Contributors must agree with the OpenDaylight Technical charter. The sign-off field is related to the role of the Certificate of Origin explained in this charter."

https://docs.opendaylight.org/en/stable-argon/_static/OpenDaylight-Technical-Charter-LFN-Projects-LLC-FINAL.pdf

Criterion [governance]
完成

不完整

?

该项目必须明确定义和记录其项目治理模式（决策方式，包括关键角色）。 (需要网址) ^[governance]
需要有一些成熟的书面方式来作出决定和解决争端。在小项目中，这可能就像“项目拥有者和负责人做所有最终决定”一样简单。有各种治理模式，包括仁慈的独裁者和正式的精英统治；有关详细信息，请参阅治理模式。集中式（例如，单一维护者）和分散式（例如，组维护者）方法都已经在项目中成功使用。治理信息不需要记录创建项目分支的可能性，因为对于FLOSS项目来说总是可能的。

This part of the technical charter https://docs.opendaylight.org/en/stable-argon/_static/OpenDaylight-Technical-Charter-LFN-Projects-LLC-FINAL.pdf

Criterion [code_of_conduct]
完成

不完整

?

该项目必须采取行为守则，并将其发布在标准的位置。 (需要网址) ^{[code_of_conduct]}
项目可能能够提高社区的文明程度，并通过采取行为守则来规定对可接受的行为的期望。这可以帮助在发生问题之前避免问题，并使项目成为更加欢迎的地方来鼓励贡献。这应该只关注项目社区/工作场所的行为。行为规范的示例是贡献者约定行为准则和Linux内核代码冲突。

Criterion [roles_responsibilities]
完成

不完整

?

该项目必须明确定义和公开记录项目中的关键角色及其职责，包括这些角色必须执行的任务。必须清楚指出谁是什么角色，尽管这可能没有以相同的方式记录下来。 (需要网址) ^{[roles_responsibilities]}
治理和角色和职责的文档可以在一个地方。

Criterion [access_continuity]
完成

不完整

?

如果任何一个开发者丧失工作能力或丧生，该项目必须能够继续保持最小的中断。特别是，在确认个人无行为能力或死亡的一周内，项目必须能够创建和关闭问题，接受提议的更改和发布软件版本。这可以通过确保其他人有任何必要的密钥，密码和合法权利来继续该项目。运行FLOSS项目的个人可以通过在锁箱中提供密钥，并提供任何所需的合法权利（例如DNS名称）来实现。 (需要网址) ^{[access_continuity]}

Criterion [bus_factor]
完成

不完整

?

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

Criterion [documentation_roadmap]
完成

不完整

?

该项目必须有一个文档化的路线图，描述项目打算做什么，至少在下一年做什么。 (需要网址) ^{[documentation_roadmap]}
项目可能没有实现路线图，没关系。路线图的目的是帮助潜在的用户和贡献者了解项目的预期方向。它不需要特别详细。

Criterion [documentation_architecture]
完成

不完整

N/A

?

该项目必须包括项目生成的软件的架构（也称为高级别设计）的文档。如果项目不产生软件，请选择“不适用”（N/A）。 (需要网址) ^{[documentation_architecture]}
软件架构解释了程序的基本结构，即程序的主要组件，它们之间的关系以及这些组件和关系的关键属性。

Criterion [documentation_security]
完成

不完整

N/A

?

该项目必须书面记录用户从项目生成的软件的安全性上可以获得和不能指望的内容（其“安全需求”）。 (需要网址) ^{[documentation_security]}
这些是软件意图满足的安全需求。

Criterion [documentation_quick_start]
完成

不完整

N/A

?

该项目必须为新用户提供“快速启动”指南，以帮助他们快速使用该软件。 (需要网址) ^{[documentation_quick_start]}
这个想法是向用户展示如何入门，使软件完全可以做事情。这对于潜在用户是至关重要的。

Criterion [documentation_current]
完成

不完整

N/A

?

项目必须努力使文档与当前版本的项目结果（包括项目生成的软件）保持一致。任何已知的文档缺陷使其不一致必须修正。如果文档基本是最新的，但是错误地包括一些不再是真实的旧信息，那么将其视为缺陷，然后像往常一样进行跟踪和修复。 ^{[documentation_current]}
该文档可以包括有关软件版本之间的差异或更改的信息，与/或链接到旧版本的文档。这个条款的意图在于努力保持文档的一致性，而不是文档必须完美。

Criterion [documentation_achievements]
完成

不完整

?

项目存储代码库首页和/或网站必须在获得成就的48小时内标识并超链接任何成就，包括此最佳实践徽章。 (需要网址) ^{[documentation_achievements]}
一个成就是项目致力于满足的任何外部条款，包括徽章。该信息不需要在项目网站首页上。使用GitHub的项目可以通过将其添加到README文件中，将成果放在存储代码库首页。
无障碍和国际化
Criterion [accessibility_best_practices]
完成

不完整

N/A

?
该项目（项目网站和项目成果）都应遵循无障碍最佳做法，使残疾人仍然可以参与项目，并在合理的情况下使用项目成果。 ^{[accessibility_best_practices]}
对于Web应用程序，请参阅 Web 内容无障碍指导 (WCAG 2.0，英文) 以及其支持文档理解 WCAG 2.0（英文）；或者 W3C 无障碍信息（英文）. 图形界面（GUI）应用考虑使用环境特定的无障碍指导（例如 Gnome, KDE, XFCE, Android, iOS, Mac, 以及 Windows). 一些TUI应用 (例如，`ncurses` 程序) 可以做一些特定的工作，增强可访问性（例如，`alpine` 的 `force-arrow-cursor` 设置）。多数命令行应用没有特别的无障碍设置。本条款经常是不涉及（N/A），例如，对于组件库。以下是一些要采取的行动或需要考虑的问题的例子：
- 提供非文字内容的文字替代，以便于转换为其他需要的格式，如大字体、盲文、语音、符号或者简单文字（ WCAG 2.0 指导 1.1 （英文）)
- 颜色不被用作传达信息，指示动作，提示响应或区分视觉元素的唯一视觉方式。 ( WCAG 2.0 指导 1.4.1（英文）)
- 文本和文字图像的视觉呈现对比度至少为4.5：1，除了大文本，次要文本和标识符之外。 ( WCAG 2.0 指导 1.4.3（英文）)
- 使用键盘可访问所有功能 (WCAG 指导 2.1)
- 图形界面应用（GUI）或者Web应用在目标平台上，应该至少使用一种屏幕阅读器测试（例如，NVDA；Jaws；Windows上的WindowEyes；Mac & iOS上的VoiceOver；Linux/BSD上的Orca；Android上的TalkBack）。TUI程序可以减少过度渲染以防止屏幕阅读器的冗余读取。
Criterion [internationalization]
完成

不完整

N/A

?

该项目产生的软件应该被国际化，以便为目标受众的文化，地区或语言进行简单的本地化。如果国际化（i18n）不适用（例如，该软件不会生成针对最终用户的文本，并且不排序可读文本），请选择“不适用”（N/A）。 ^{[internationalization]}
本地化“是指适应产品，应用或文档内容以满足特定目标市场（语言环境）的语言，文化和其他要求。国际化是“设计和开发产品，应用或文档内容，使不同文化，地区或语言的目标受众更容易本地化”。（请参阅 W3C的“本地化与国际化”）。软件只需通过国际化即可达到此标准。不需要另一种特定语言的本地化，因为一旦软件已被国际化，其他人就可以从事本地化。
其他

Criterion [sites_password_security]
完成

不完整

N/A

?

如果项目站点（网站，存储库和下载URL）存储用于外部用户认证的密码，则必须使用密钥拉伸（迭代）算法将密码存储为具有每用户盐值的迭代散列（例如，PBKDF2，Bcrypt或Scrypt）。如果项目站点不存储密码，请选择“不适用”（N/A）。 ^{[sites_password_security]}
请注意，使用 GitHub 符合此条款。此条款仅适用于用于外部用户认证到项目站点的密码。如果项目站点必须登录到其他站点，则可能需要为此目的存储密码（因为使用像Bcrypt这样的算法会使这些密码无效）。本条款将 crypto_password_storage 条款应用于项目站点，类似于sites_https条款。

变更控制 1/1 ●

之前的版本

Criterion [maintenance_or_update]
完成

不完整

N/A

?

该项目必须维护最常用的旧版本的产品或提供较新版本的升级路径。如果升级路径很困难，项目必须记录如何执行升级（例如，给出更改的接口描述和详细的建议步骤以帮助升级）。 ^{[maintenance_or_update]}

We maintain three overlapping releases, with 6 months upgrade cadence. Upgrades are guaranteed to work between subsequent major versions, but oftentimes work even across multiple major versions. Upgrade guides for each release are maintained in the release notes, for example: https://docs.opendaylight.org/en/latest/release-notes/upgrade-process.html If extraordinary upgrade steps are required, these are typically carried in per-subproject release notes.

分析 2/2 ●

静态代码分析

Criterion [static_analysis_common_vulnerabilities]
完成

不完整

N/A

?

如果至少有一个FLOSS工具能够以所选择的语言实现此条款，则该项目必须至少使用一个具有规则或方式的静态分析工具来查找分析语言或环境中的常见漏洞。 ^{[static_analysis_common_vulnerabilities]}
专门设计用于寻找常见漏洞的静态分析工具更有可能找到它们。也就是说，使用任何静态工具通常会帮助找到一些问题，所以我们“通过”级别的徽章建议，但不要求这个条款。

SonarCloud
动态代码分析

Criterion [dynamic_analysis_unsafe]
完成

不完整

N/A

?

如果由项目生成的软件包含使用内存不安全语言编写的软件（例如，C或C ++），则项目必须至少使用一个动态工具（例如，fuzzer或web应用扫描程序）与一种检测缓冲区覆写等内存安全问题的机制组合例行使用。如果项目不生成以内存不安全语言编写的软件，请选择“不适用”（N/A）。 ^{[dynamic_analysis_unsafe]}
检测内存安全问题的机制的示例包括AddressSanitizer（ASAN）（可在GCC和LLVM中使用），“Memory Sanitizer”和 valgrind 。其他可能使用的工具包括ThreadSanitizer和UndefinedBehaviorSanitizer。广泛的断言也将起作用。

Java is a memory-safe language. Other languages are mainly used for testing purposes.

此数据在知识共享署名3.0或更高版本许可证（CC-BY-3.0 +）下可用。所有内容都可以自由分享和演绎，但必须给予适当的署名。请署名为Casey Cain和OpenSSF最佳实践徽章贡献者。

OpenDaylight

基本 3/17 ●

识别

先决条件

基本项目网站内容

项目监督

文档

无障碍和国际化

其他

变更控制 1/1 ●

之前的版本

报告 1/3 ●

错误报告流程

漏洞报告流程

质量 13/19 ●

编码标准

可工作的构建系统

安装系统

外部维护的组件

自动测试套件

新功能测试

警告标志

安全 0/13 ●

安全开发知识

使用基础的良好加密实践

安全发布

其他安全问题

分析 2/2 ●

静态代码分析

动态代码分析