<Project> Scorecard

<Project> Scorecard

This document template is meant to be used as a scorecard to assess how a project eligible for inclusion meets the Neutron Stadium requirements as defined in this specification. If the outcome of the assessment is negative, the project inclusion is rejected.

Neutron integration

  • N0. Does the project use the Neutron REST API or rely on proprietary backends?
  • N1. Does the project integrate/use neutron-lib?
  • N2. Do project members actively contribute to help neutron-lib achieve its goal?
  • N3. Do project members collaborate with the core team to enable subprojects to loosely integrate with the Neutron core platform by helping with the definition of modular interfaces?
  • N4. How does the project provide networking services? Does it use modular interfaces as provided by the core platform?
  • N5. If the project provides new API extensions, have API extensions been discussed and accepted by the Neutron drivers team? Please provide links to API specs, if required.


  • D1. Does the project have a doc tox target, functional and continuously working? Provide proof (e.g. links to logs.openstack.org).
  • D2. If the project provides API extensions, does the project have an api-ref tox target, functional and continuously working? Provide proof (e.g. links to logs.openstack.org).
  • D3. Does the project have a releasenotes tox target, functional and continuously working? Provide proof.
  • D4. Describe the types of documentation available: developer, end user, administrator, deployer.

Continuous Integration

  • C1. Does the project have a Grafana dashboard showing historical trends of all the jobs available? Provide proof (links to grafana.openstack.org).
  • C2. Does the project have CI for unit coverage? Provide proof (links to logs.openstack.org).
  • C3. Does the project have CI for functional coverage? If so, does it include DB migration and sync validation?
  • C4. Does the project have CI for fullstack coverage?
  • C5. Does the project have CI for Tempest coverage? If so, specify nature (API and/or Scenario).
  • C6. How does a project validate upgrades on a continuous basis? Does the project require or support CI for Grenade coverage?
  • C7. Does the project provide multinode CI?
  • C8. Does the project support Python 3.x? Provide proof.

Release footprint

  • R1. Does the project adopt SemVer?
  • R2. Does the project have release deliverables? Provide proof as available in the release repo.
  • R3. Does the project use upper-constraints?
  • Does the project integrate with OpenStack Proposal Bot for requirements updates?

Stable backports

  • S1. Does the project have stable branches and/or tags? Provide history of backports.

Client library

  • L1. If the project requires a client library, how does it implement CLI and API bindings?


N0 |
N1 |
N2 |
N3 |
N4 |
N5 |
D1 |
D2 |
D3 |
D4 |
C1 |
C2 |
C3 |
C4 |
C5 |
C6 |
C7 |
C8 |
R1 |
R2 |
R3 |
R4 |
S1 |

Final remarks: (To be compiled by PTL).

Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.