Rather than establish a project for OpenDaylight, the OPNFV community has agreed to work on establishing focus community groups where we will describe community engagement practices, identify community leaders, manage our contributions toward those communities and generally get ourselves organised well enough to be a benefit, rather than a burden, to our source communities.

In general, we would like to have a consistent process for feature requests across OPNFV projects. Since the bar in terms of structure and information seems to be highest for OpenStack, we will align feature request documentation on the OpenStack blueprint process. The process is defined for requirements projects.

In short, projects should create a high-level OPNFV requirements document, an OpenDaylight blueprint, and after an OPNFV review, should transition to upstream projects for community review and discussion.

1. Projects first create an OPNFV requirement document in Markdown in the project repository: repository/requirements/reference_document.rst - this document should describe the goal at a high level for ONFV consumers
2. A requirement will result in one or more blueprints for a project which should be drafted (one blueprint per file) in repository/design_docs/reference_document.rst - if features affect multiple projects, there should be a single blueprint per project
3. These files should be proposed for review in OPNFV's Gerrit, and should follow the OpenStack blueprint template format (example for Ceilometer)
4. After a successful community sanity check, verifying that the spec has sufficient implementation details and conforms with the minimum expectations of an OpenDaylight feature request, the blueprint should be proposed to the upstream project.

OpenDaylight is a collection of loosely affiliated projects, under a common project umbrella. Projects commit to a simultaneous release process with a series of milestones. How the projects organise themselves within that release process is a matter for the project developers.

OpenDaylight projects are organised into three groups:

• Offset 0: Core projects, required by all others: Controller, yangtools, odlparent
• Offset 1: Key network services required by other projects: OVSDB, OpenFlow, Neutron NB, topology manager, …
• Offset 2: No projects depend on these to operate. Some examples relevant to OPNFV are SFC, GBP, VPN Service, …

Projects in Offset 1 typically have deadlines set 1 or 2 weeks after Offset 0 projects, and Offset 2 projects are similarly offset from Offset 1.

Key milestones:

• M0: Release plan is approved (immediately after previous release)
• 2-4 weeks after M0: New project proposal deadline. New projects require a 2 week discussion period.
• M1: New project approval deadline. Projects should have a leader and a draft release plan.
• M2: 6 weeks after M1. Projects should have finalised release plan and completed the project checklist
• M3: 4 weeks after M2 (+2 weeks for Offset 1, +4 weeks for Offset 2): Functionality freeze, external APIs published, Karaf features defined
• M4: 4 weeks after M3: API freeze, documentation, integration test plan deliverables
• M5: 4 weeks after M4: Code freeze, stable branch creation

Release candidates will be made as necessary, starting 6 weeks after M5 (all projects commit to RC dates).

Table with OPNFV-related projects, links to their feature planning, mailing list and other relevant information.