The community members should continue to contribute across different projects. If there are dependencies across projects a contribution to overcome them is the best way to keep moving forward.
Willingness to help on-board new members (e.g. on IRC)
Great leadership from the Functest project team who had to step forward in the past few months and manage the transition.
Engagement with upstream communities (e.g. impact recently at the OpenStack Summit)
Burden on a small number of SMEs as was also highlighted in other email threads
Should be more clear on the areas where we need resources will help our members and the broader community find the right people to have involved
Discussed more resource needed for
ODL SME
Maybe OSGI/Karaf people to help with platform issues you see on ODL or ONOS
People who are in telco operations who are actively deploying applications today and can provide feedback
Testing competencies, with broad experience in testing for application deployment scenarios
Collaboration with SDOs
More resource on training and on-boarding is needed (both for new developers & users)
Better project information/dashboard will be helpful for people that are new to the project
Project Management
Scope management
Within 2 months of project launch, there was a relatively clear idea of the Arno scope. This reduction in scope was a contributing factor in being able to deliver.
The communication of the Arno scope after the decision was made could have been better
Not having a clear idea of the resources available made it very difficult to manage the risk of the scope
There was not a change management process for decision making during Arno and better communication could have reduced friction
On change management, there's a need to be wary of imposing too much top-down control/benediction of project leaders vs allowing leaders to arise organically as we grow as a community.
A structured approach to using Jira would be helpful in coordinating community efforts
Schedule
Additional effort is needed to address risk mitigation when making our plans
Successful time-based projects manage releases by gating early on feature readiness and gating early
Establishing clear milestones and being concise on the meaning of those milestones and qualifications will be important
Individual projects will have their own timeline that may or may not coincide with a time-based release activity. We need to be clear on the correlation between release and content.
Discussion that it may be acceptable to set our release date based on upstream dependencies rather than trying to stay to a completely time-based release cycle.
There was a discussion about release cadence, and how features will make it from upstream into a release.
There is not a shared understanding of what a "release" means, what release artifacts the project will create, or even what it means to be in a release
Project resources
Multiple timezones require effective communications in the community.
Discussion on challenges with the OPNFV hardware in the LF lab. A question was raised if there is a way to automate a lot of activities on the LF hardware.