BadgeApp

Basics 13/13 ●

Identification

What is the human-readable name of the project?
Note that other projects may use the same name.
What is a brief description of the project?
ONAP VNFSDK's mission is to simplify the process of developing and onboarding VNFs and expanding ONAP's VNF ecosystem. For Service Providers, VNFSDK will reduce the time and level of testing required to identify, select, and onboard a VNF. For vendors, VNFSDK will reduce integration efforts by defining a standard for VNF packaging with widespread operator acceptance. VNFSDK can be used in a validation/conformance testing program in the future.

VNFSDK delivers automation tools for VNF product specification, packaging, publication and ingestion. This project will also deliver a tool for:
```
package validation,
lifecycle test (framework)
functional test (framework)
Reference Repository for VNFs to enable CI/CD without dependency on service provider ingestion
```
What is the URL for the project (as a whole)?
https://wiki.onap.org/display/DW/VNF+SDK+Project

What is the URL for the version control repository (it may be the same as the project URL)?
https://gerrit.onap.org/r/admin/repos/q/filter:vnfsdk

What programming language(s) are used to implement the project?
If there is more than one language, list them as comma-separated values (spaces optional) and sort them from most to least used. If there is a long list, please list at least the first three most common ones. If there is no language (e.g., this is a documentation-only or test-only project), use the single character "-". Please use a conventional capitalization for each language, e.g., "JavaScript".

Implementation languages

What is the Common Platform Enumeration (CPE) name for the project (if it has one)?
The Common Platform Enumeration (CPE) is a structured naming scheme for information technology systems, software, and packages. It is used in a number of systems and databases when reporting vulnerabilities.
Basic project website content

Criterion [description_good]
Met

Unmet

?

The project website MUST succinctly describe what the software does (what problem does it solve?). ^{[description_good]}
This MUST be in language that potential users can understand (e.g., it uses minimal jargon).

The description of the project can be found in http://onap.readthedocs.io/en/latest/submodules/vnfsdk/model.git/docs/release-notes.html

Criterion [interact]
Met

Unmet

?

The project website MUST provide information on how to: obtain, provide feedback (as bug reports or enhancements), and contribute to the software. ^[interact]

The following URLs describe the process to join the community, developing the software and provide feekback: https://wiki.onap.org/display/DW/Joining+the+Community https://wiki.onap.org/display/DW/Tracking+Issues+with+JIRA https://wiki.onap.org/display/DW/Developing+ONAP

Criterion [contribution]
Met

Unmet

?

La información sobre cómo contribuir DEBE explicar el proceso de contribución (por ejemplo, ¿se utilizan "pull requests" en el proyecto?) (URL required) ^{[contribution]}
Se asume que los proyectos en GitHub usan "incidencias" y "pull requests" a menos que se indique lo contrario. Esta información puede ser breve, por ejemplo, indicando que el proyecto utiliza "pull requests", un gestor de incidencias o publicaciones en una lista de correo (Indíquese cuál)

The process could be found in the following URL: https://wiki.onap.org/display/DW/Development+Procedures+and+Policies

Criterion [contribution_requirements]
Met

Unmet

?

The information on how to contribute SHOULD include the requirements for acceptable contributions (e.g., a reference to any required coding standard). (URL required) ^{[contribution_requirements]}

The Javascript code should meet the requirements except for the number of characters in a line of code specified by the styleguide https://google.github.io/styleguide/jsguide.html We avoid the restriction on the number of characters in one line of code to improve readability.
FLOSS license

What license(s) is the project released under?
Please use SPDX license expression format; examples include "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT", and "(BSD-2-Clause OR Ruby)". Do not include single quotes or double quotes.

License
Criterion [floss_license]
Met

Unmet

?
The software produced by the project MUST be released as FLOSS. ^{[floss_license]}
FLOSS is software released in a way that meets the Open Source Definition or Free Software Definition. Examples of such licenses include the CC0, MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), and the GNU General Public License (GPL). For our purposes, this means that the license MUST be:
The software MAY also be licensed other ways (e.g., "GPLv2 or proprietary" is acceptable).
The Apache-2.0 license is approved by the Open Source Initiative (OSI).
Criterion [floss_license_osi]
Met

Unmet

?

It is SUGGESTED that any required license(s) for the software produced by the project be approved by the Open Source Initiative (OSI). ^{[floss_license_osi]}
The OSI uses a rigorous approval process to determine which licenses are OSS.

The Apache-2.0 license is approved by the Open Source Initiative (OSI).

Criterion [license_location]
Met

Unmet

?

The project MUST post the license(s) of its results in a standard location in their source repository. (URL required) ^{[license_location]}
One convention is posting the license as a top-level file named LICENSE or COPYING, which MAY be followed by an extension such as ".txt" or ".md". An alternative convention is to have a directory named LICENSES containing license file(s); these files are typically named as their SPDX license identifier followed by an appropriate file extension, as described in the REUSE Specification. Note that this criterion is only a requirement on the source repository. You do NOT need to include the license file when generating something from the source code (such as an executable, package, or container). For example, when generating an R package for the Comprehensive R Archive Network (CRAN), follow standard CRAN practice: if the license is a standard license, use the standard short license specification (to avoid installing yet another copy of the text) and list the LICENSE file in an exclusion file such as .Rbuildignore. Similarly, when creating a Debian package, you may put a link in the copyright file to the license text in /usr/share/common-licenses, and exclude the license file from the created package (e.g., by deleting the file after calling dh_auto_install). We encourage including machine-readable license information in generated formats where practical.

License can be found in: https://gerrit.onap.org/r/gitweb?p=vnfsdk/pkgtools.git;a=blob;f=LICENSE;

Other files explicitly call out the Apache 2 license directly.
Documentation

Criterion [documentation_basics]
Met

Unmet

N/A

?

The project MUST provide basic documentation for the software produced by the project. ^{[documentation_basics]}
This documentation must be in some media (such as text or video) that includes: how to install it, how to start it, how to use it (possibly with a tutorial using examples), and how to use it securely (e.g., what to do and what not to do) if that is an appropriate topic for the software. The security documentation need not be long. The project MAY use hypertext links to non-project material as documentation. If the project does not produce software, choose "not applicable" (N/A).

http://onap.readthedocs.io/en/latest/submodules/vnfsdk/model.git/docs/index.html

Criterion [documentation_interface]
Met

Unmet

N/A

?

The project MUST provide reference documentation that describes the external interface (both input and output) of the software produced by the project. ^{[documentation_interface]}
The documentation of an external interface explains to an end-user or developer how to use it. This would include its application program interface (API) if the software has one. If it is a library, document the major classes/types and methods/functions that can be called. If it is a web application, define its URL interface (often its REST interface). If it is a command-line interface, document the parameters and options it supports. In many cases it's best if most of this documentation is automatically generated, so that this documentation stays synchronized with the software as it changes, but this isn't required. The project MAY use hypertext links to non-project material as documentation. Documentation MAY be automatically generated (where practical this is often the best way to do so). Documentation of a REST interface may be generated using Swagger/OpenAPI. Code interface documentation MAY be generated using tools such as JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python), devtools (R), pkgdown (R), and Doxygen (many). Merely having comments in implementation code is not sufficient to satisfy this criterion; there needs to be an easy way to see the information without reading through all the source code. If the project does not produce software, choose "not applicable" (N/A).

http://onap.readthedocs.io/en/latest/submodules/vnfsdk/model.git/docs/files/vnfsdk-apis.html
Other

Criterion [sites_https]
Met

Unmet

?

The project sites (website, repository, and download URLs) MUST support HTTPS using TLS. ^{[sites_https]}
This requires that the project home page URL and the version control repository URL begin with "https:", not "http:". You can get free certificates from Let's Encrypt. Projects MAY implement this criterion using (for example) GitHub pages, GitLab pages, or SourceForge project pages. If you support HTTP, we urge you to redirect the HTTP traffic to HTTPS.

https://wiki.onap.org/display/DW/VNF+SDK+Project https://gerrit.onap.org/r/#/admin/projects/vnfsdk

Criterion [discussion]
Met

Unmet

?

The project MUST have one or more mechanisms for discussion (including proposed changes and issues) that are searchable, allow messages and topics to be addressed by URL, enable new people to participate in some of the discussions, and do not require client-side installation of proprietary software. ^[discussion]
Examples of acceptable mechanisms include archived mailing list(s), GitHub issue and pull request discussions, Bugzilla, Mantis, and Trac. Asynchronous discussion mechanisms (like IRC) are acceptable if they meet these criteria; make sure there is a URL-addressable archiving mechanism. Proprietary JavaScript, while discouraged, is permitted.

A mailing list is used for project related discussion. New users could also check, search the old discussion online at onap-discuss website. https://wiki.onap.org/display/DW/Joining+the+Community

Criterion [english]
Met

Unmet

?

The project SHOULD provide documentation in English and be able to accept bug reports and comments about code in English. ^[english]
English is currently the lingua franca of computer technology; supporting English increases the number of different potential developers and reviewers worldwide. A project can meet this criterion even if its core developers' primary language is not English.

JIRA is used to track bugs. The whole website is in English. https://wiki.onap.org/display/DW/Tracking+Issues+with+JIRA

Criterion [maintained]
Met

Unmet

?

The project MUST be maintained. ^[maintained]
As a minimum, the project should attempt to respond to significant problem and vulnerability reports. A project that is actively pursuing a badge is probably maintained. All projects and people have limited resources, and typical projects must reject some proposed changes, so limited resources and proposal rejections do not by themselves indicate an unmaintained project.

When a project knows that it will no longer be maintained, it should set this criterion to "Unmet" and use the appropriate mechanism(s) to indicate to others that it is not being maintained. For example, use “DEPRECATED” as the first heading of its README, add “DEPRECATED” near the beginning of its home page, add “DEPRECATED” to the beginning of its code repository project description, add a no-maintenance-intended badge in its README and/or home page, mark it as deprecated in any package repositories (e.g., npm deprecate), and/or use the code repository's marking system to archive it (e.g., GitHub's "archive" setting, GitLab’s "archived" marking, Gerrit's "readonly" status, or SourceForge’s "abandoned" project status). Additional discussion can be found here.

(Advanced) Disable inactivity reminder (we recommend you leave this unchecked; note that project entries must be edited to change whether or not reminders are sent)

(Advanced) What other users have additional rights to edit this badge entry? Currently: [3192, 5993]

Other general comments about the project:

This data is available under the Creative Commons Attribution version 3.0 or later license (CC-BY-3.0+). All are free to share and adapt the data, but must give appropriate credit. Please credit mrsjackson76 and the OpenSSF Best Practices badge contributors.

ONAP VNFSDK

Basics 13/13 ●

Identification

Basic project website content

FLOSS license

Documentation

Other

Change Control 9/9 ●

Repositorio público para el control de versiones de código fuente

Numeración única de versión

Notas de lanzamiento

Informes 8/8 ●

Bug-reporting process

Proceso de informe de vulnerabilidad

Calidad 13/13 ●

Working build system

Automated test suite

New functionality testing

Banderas de advertencia

Seguridad 16/16 ●

Conocimiento de desarrollo seguro

Use buenas prácticas criptográficas

Entrega garantizada contra ataques de hombre en el medio (MITM)

Vulnerabilidades públicamente conocidas corregidas

Otros problemas de seguridad

Analysis 8/8 ●

Análisis estático de código

Dynamic code analysis