Community Feedback

Issues

• Meeting times

• TSC not technical enough, lack of leadership.  Solve technical problems across projects when teams have trouble passing milestones.

• Projects spending too much time on architecture/modeling, and not enough on code (how we can help PTL to deliver code ?)

• Digest news from wiki, mailing lists on a weekly/monthly basis (newsletter?)

• Prioritize TSC agenda/time to focus on high-priority (like code and solution delivery)

• JIRA for TSC decisions to make sure we follow up

• wiki internal organization (hard to find things under current structure)

• Streamline ONAP - core projects + "add-ons"

• Community still behaving in startup mode - development done inside companies, and dumped as seed code into projects, rather than transparent development in the projects

• ONAP should behave more like a meritocracy. Projects added based on value to companies. Incubation area?  Approval criteria: significant commits from 3+ companies?

• TSC membership - lose membership if you miss more than a certain number of meetings?

• Too many private email exchanges. Use public forums.

• Message board, especially close to the release. Reminders on upcoming milestones/project issues.

• TSC members shepherd projects?

• #1 issue is ease of joining ONAP for a newbie

• improve documentation

• be willing to close things. Too many subcommittees/tiger teams?

• action register for TSC

• prioritize/differentiate threads, triage and delegate threads, dashboard for status

• Need all TSC members to be very comfortable with microservice design principles, technologies and implementations to drive the right technical direction for various ONAP projects and ONAP platform as a whole; currently this seems to be lacking

• wiki should be better organized e.g. a single place holder for all documents with tags on which subcommittees/projects etc. these documents belong to, a single placeholder for each release's approved documents

• Still strong top-down approach on most of the project (JIRA driven management even on Master)

• Hard to get resources (repo) to expose new code out of JIRA way

• NIH, leverage of other existing LF projects vould be better

• Code review rules not consistent and sometimes light if not bypassed (1 single +2 then merge without real review)

• Light and/or inconsistent minute meetings across the different projects (wiki/video/mail..)..poor IRC notes (action points) which is the usual way (used in most of the Open Source communities)

• Goals sometimes too ambitious for version N+1 leading to some confusion between what the community would like and what it can achieve

• Support/Jenkins rights not provided for all the time zones. Impossible to manually triggers jobs from CEST, need to wait for people in PDT to trigger jobs, which slow down the integration

• Decisions are being made on versioning, release process, CI/CD configuration by non-TSC teams that seem to handcuff the PTL's without their say in the matter. 
  
  
  

Root Causes

Suggestions and discussion

• PTLs and TSC members fairly easy to track and raise flag in case of lack of activity

• TSC meeting time should be shorten to 1 hour - so people in China suffer less due t late evening hours. We should clearly define what are topics on agenda for TSC meetings, and then also:

  • what can be discussed by some form of active chat (yet to be defined)

  • What may be discussed in bi or 3 - weekly meetings, which are also scheduled in advance

• The rule of not having meetings from 12 to 6 am should always be enforced

• We do need to encourage and listen to the concerns more.  There was the feedback “Opposing Community viewpoints or concerns are often marginalized”, then when the timezone of the meetings was raised it was quickly dismissed - as an example.

  • We do have some hard constraints in ONAP.  Looking at Bitergia as a proxy for where we're located, we see:

  •  

    Open

    

  • If we want to avoid the hours of midnight-6 am (as per above), that leaves three hours in the summer and two hours in the winter (assuming every geography is represented).  It's not good for either China or the US West Coast, but there isn't another 6+ hour gap in the day.

•  Maybe we need to make the TSC meeting 2 hours (may only worsen the problem)

• Feedback from several community members received during last week:

  • As long as there is no “user/operator advisory board” the TSC has the dual role of both representing the community as well as the needs and desires of “companies”. If the TSC becomes only community focused there is a risk of it becoming an echo chamber for the developer’s community, without enough focus on the requirements of the users.

    <suggestion> - Create an active “user advisory board” that will represent “companies”, leaving the TSC to the “community”

  • This may not be enough incentive for individuals to engage beyond their organizations activities. Considering the other challenges mentioned in this list, such engagement may be frustrating.

    <suggestion> recognize, and perhaps reward, individuals that are engaged in a positive way. Also, set the expectations correctly. People will almost always prioritize their employer goals over those of the community. This is what they are measured for.

  • The only form of conversation is weekly calls, where the agenda is overbooked, and time is short. This is not an environment that encourages discussion. Some participants may not feel comfortable expressing their opinion in a 100 participant conference call.

    <suggestion> The community should establish other methods of dialog. We should really find a method to conduct chats that works for everyone. Also, we should establish a proper etiquette for using comments in Wiki pages, and make them a more efficient tool. Currently the comment exchange seems to be inefficient and “best effort”

  • Considering the size of the community it is OK to have smaller teams work on proposals that are later shared with the community. However it seems that such teams become permanent.

    <suggestion> - Limit the life span of such tiger teams. Set clear goals to teams and agree on deliverables in advance. Once the goals are met and the outputs delivered, the team should be dissolved.

-          The TSC agenda management and time management could improve to get the most out of the time.  We also need to move from reporting to discussions/decisions that assist the community.  Maybe split the into 3 parts (though maybe 2 parts depending on where we are in the release).  Time cap (can’t put all that on LF).

• Current Release issues.

  • Here, not just reporting but discussion about what we need to do to secure the release etc.

• Next Release issues

• General community and admin

• To do this, we need to encourage more input on the agenda topics in advance.

-          We don’t do decision follow-up very well.  We have made decisions with no follow-up. We could consider TSC level “Jiras” for topics or issues to address to help with the TSC project management.

• There was an action taken to return with a proposal regarding the review of the project scopes, nothing done

• We don’t have the sub-committee updates on the rotating basis – which should be less about “information” more about “here are the decisions required”.

-          For the common way to store minutes across the projects etc; maybe we need to have a best practice project/subcommittee that the rest can slowly adopt to.  And follow-up.

• We don't use all of the TSC members in the community.  A few are involved with sub-committees etc, and some in projects.  We could look at also assigning project support of some TSC members to groups of projects so that they have a TSC member to be a point of contact to represent their concerns, questions, etc and to lead the related discussion in the meetings.

•  Missing f/b from the board meetings and related discussions about what it means for ONAP.

• Document placement on wiki should be much better organized. The proposal is to have a single storage place for ALL submitted documents by tagging where specific document belongs to

• We may need to have agreed requirements' terminology e.g. "shall", "should", "may" across a different architecture, use cases, modelling, security etc. activities

• A special folder with release's approved documents should be created (for easier reference by another committees/orgs)

• PTL's should be allowed to vote on process changes that affect the way they deliver their components

Agreed action plan

4/12/18 Recording: audio_only.m4a