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