- 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
- 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
- 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.
4/12/18 Recording: audio_only.m4a