User Tools

Site Tools


retropectives:arno

Arno Retrospective

Positives

  • Cross team/project collaboration
    • 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)
  • Good visibility of Arno on social channels

Community

  • 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.

MeetBot Minutes

retropectives/arno.txt · Last modified: 2015/06/13 21:49 by Ray Paik