...
- 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
Root Causes
Suggestions and discussion
...