...
- When you are a mailing list moderator do not approve subscription requests from accounts with obviously pornographic domain names. (yes, this really happened. recently.)
- Lack of transparency on LF IT ticket raised by the community. The LF RT tools has poor capability to email properly the whole set of information. The ONAP community has no visibility on what LF IT is currently working on.
- Feedback compiled by Kenny Paulfrom ONS-NA: (See TSC 2018-04-05 Agenda slides)
Onboarding an engineer is very hard; The wiki isn’t laid out well and is confusing, needs to be cleaned up
Responsiveness from existing Community members answering new contributor questions can be a challenge
- All approved projects should be required to post meeting minutes to the wiki
The volume of untagged emails makes filtering almost impossible
- Need absolutely clear and unambiguous validation that RocketChat can be used via https from China and most companies without requiring a VPN, or the use of an alternative device/network -kenny:. Must be secured if setup by LF (simply b/c of well known pwd).
- Would like the Community to decide whether the use of IRC as the "official" minute mechanism is a practice worth continuing or not; very few people are using it, many can't use it and unlike other communities, virtually no one contributes to the minutes. Compare that with the fact that everyone can use zoom chat and there is always a great deal of contribution being performed there. -kenny
- WIKI Help: things are hard to find unless you type the right keywords or have the proper URL. Some information no more accurate. Matter of organization, not matter of quantity of information. Recommendation to use ReadTheDocs to start versus the wiki? Another approach may be to make Wiki searches more deficient by publishing and enforcing guidelines for usage of page names and lables.
- WIKI: Onboarding new community members is the challenge.
- Is there a good enough flow of information-communication between sub-committees and projects? Overall: yes. Sub-committee feedback of to the TSC is not systematic(as we wish).
- Expectation from sub-sub-committee back to the team and then driving the execution. Use-case owner is missing. Use-case team to fill a checklist? We may defined what that role is.
...
- Need for simplifying ONAP Micro-Service architecture by leveraging best practices from Industry :
- Certificate enrollment (for Mutual TLS communication among services) in Beijing was manual, time consuming and error prone. Need automation of certificate enrollment is needed.
- Scale-out of ONAP is removed from the scope in Beijing release. Services that attempt do it has some learnings. Scale-Out/Load balancing/Circuit-breaking/DB-sync related functionality should be removed from actual micro services to sidecars/side-kicks to avoid each developer spending time and getting it right.
- Need share as much as possible the building blocks with regarding to the implementation of new ONAP Micro-services
- While the community focus on more about the micro-service arch. the diversity of building blocks for each micro-services complicates the debug/maintain effort for everyone willing to exercise/develop existing/new use cases. e.g. While java and python language are prevalent used for each most of micro-services, some other language binding(e.g. golang) was introduced as well. so whoever want to debug those microservices will have to either seek the help from community (with no promise to get timely support) or have to learn those language/framework,etc. This apparently hinder the adoption of some ONAP components, even they complies to micro-services architecture. I suggest each team should evaluate/review carefully what kind of building blocks are utilized instead of the choice to the contributors only. The principle is : whenever it is possible, the existing building blocks should be considered as preferred choices.
- New project introduction
- New projects that are in "incubation" stage should not be a dependency for the rest of the mature projects. This will avoid introducing new complexities to the process of deploying and running ONAP.
- Only when a project graduates from their incubation stage should other projects create such dependencies.
• Use cases:
- Increase the scope of vCPE use case in deploying multiple virtual Gateways (Multi-Customer support)
...