BadgeApp

基本 13/13 ●

识别

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

什么是项目的简要描述？

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

用什么编程语言实现项目？
如果有多种语言，请将它们列为逗号分隔值（可选空格），并将它们从最多到最少使用。如果有长列表，请至少列出前三个最常见的列表。如果没有语言（例如，这是仅文档或仅测试项目），请使用单个字符“ - ”。请使用每种语言的常规大小写，例如“JavaScript”。

Implementation languages

项目的通用平台枚举（CPE）名称（如果有）？
通用平台枚举（CPE）是用于信息技术系统，软件和软件包的结构化命名方案。在报告漏洞时，它可用于多个系统和数据库。
基本项目网站内容

Criterion [description_good]
完成

不完整

?

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

OpenDaylight: Open Source SDN Platform Software-Defined Networking (SDN) is an industry movement for building programmable networks that are flexible and responsive to organizations' and users' needs.

Criterion [interact]
完成

不完整

?

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

docs.opendaylight.org wiki.opendaylight.org

Criterion [contribution]
完成

不完整

?

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

Project uses pull requests. https://docs.opendaylight.org/en/latest/#contributing-to-opendaylight
Criterion [contribution_requirements]
完成

不完整

?

关于如何贡献的信息应包括对可接受的贡献的要求（例如，引用任何所需的编码标准）。 (需要网址) ^{[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.
```
FLOSS许可证

项目使用什么许可证发布？
请使用 SPDX许可证表达格式;例子包括“Apache-2.0”，“BSD-2-Clause”，“BSD-3-Clause”，“GPL-2.0+”，“LGPL-3.0 +”，“MIT”和“(BSD-2-Clause OR Ruby)”。

License
Criterion [floss_license]
完成

不完整

?
项目生产的软件必须作为FLOSS发布。 ^{[floss_license]}
FLOSS是以符合开源定义或免费软件定义。此类许可证的示例包括 CC0 ， MIT ， BSD 2条款， BSD 3条款修订版， Apache 2.0 ， Lesser GNU通用公共许可证（LGPL），以及 GNU通用公共许可证（GPL）。为了我们的目的，这意味着许可证必须是：
该软件也可以用其他许可证（例如，“GPLv2或专有”是可以接受的）。
The EPL-1.0 license is approved by the Open Source Initiative (OSI).
Criterion [floss_license_osi]
完成

不完整

?

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

The EPL-1.0 license is approved by the Open Source Initiative (OSI).

Criterion [license_location]
完成

不完整

?

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

https://github.com/opendaylight/controller/blob/master/LICENSE
文档

Criterion [documentation_basics]
完成

不完整

N/A

?

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

https://docs.opendaylight.org

Criterion [documentation_interface]
完成

不完整

N/A

?

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

https://docs.opendaylight.org
其他

Criterion [sites_https]
完成

不完整

?

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

Given only https: URLs.

Criterion [discussion]
完成

不完整

?

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

All meetings, with the exception of the Board meeting are open to the public, recorded and archived on the OpenDaylight Wiki. https://wiki.opendaylight.org/view/Meetings

Criterion [english]
完成

不完整

?

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

https://docs.opendaylight.org

Criterion [maintained]
完成

不完整

?

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

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

（高级）禁用不活动提醒（我们建议您取消选中此选项）

（高级）哪些用户还有额外权限编辑此徽章条目？目前：[2871, 11644]

大多数项目应忽略此字段。项目徽章条目可以由徽章条目所有者（创建者），BadgeApp管理员以及任何可以提交给GitHub存储库（如果在GitHub上）的人员进行编辑。如果您希望其他人能够编辑此徽章条目，并且您已具有此项目徽章条目的编辑权限，则可以为其他用户提供编辑权限。只需输入“+”，后跟一个逗号分隔的整数用户ID列表。那么这些用户也将被允许编辑此项目条目。如果您是徽章条目的所有者或BadgeApp管理员，则可以通过输入“ - ”，后跟逗号分隔的整数用户ID列表，从该列表中删除用户。如果多个用户尝试同时编辑，此应用程序使用乐观锁定机制来防止保存过期数据。只有此项目条目的所有者和BadgeApp管理员才能更改此字段。

关于该项目的其他一般性意见：

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

OpenDaylight

基本 13/13 ●

识别

基本项目网站内容

FLOSS许可证

文档

其他

变更控制 9/9 ●

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

唯一版本编号

发行说明

报告 8/8 ●

错误报告流程

漏洞报告流程

质量 13/13 ●

可工作的构建系统

自动测试套件

新功能测试

警告标志

安全 15/16 ●

安全开发知识

使用基础的良好加密实践

安全交付防御中间人（MITM）的攻击

修正公开的漏洞

其他安全问题

分析 8/8 ●

静态代码分析

动态代码分析