...
Suggestions and discussion
- PTLs and TSC members fairly easy to track and raise flag in case of lack of activityactivity
- 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:
-
- 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).
...
- 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