A page to post the findings of the 2016 community survey and to list the actions proposed to address concerns raised in findings.

Findings

The community survey identified four areas for us to focus on improving:

• We need to increase transparency

• We need to have better documentation and review technical procedures

• We need to avoid ON.Lab staff becoming a bottleneck

• We need to reduce barriers to contribution

More details about the findings can be found at:

• Diagnosis: ONOS Community Survey 2016 (Interim report)
• ONOS Community Survey Results (Final report)

Recommended Actions

We need to increase transparency

We gathered recommendations on this topic through a TST meeting, multiple CST meetings, blog post, Twitter and mailing list discussion.

• Move off of Google Hangouts as a videoconference system since it is inaccessible to community in China and to people in some organizations
• Post a Roadmap page on the wiki that contains an easy to find list of upcoming features and how to get involved with each
• Post notes of key meetings in addition to video or audio recordings of those meeting since people don't tend to watch an hour long recording of a meeting (for instance, the recording of the March 30 TST meeting has 56 views as of May 18 and that equals 6% of the 914 subscribers of the onos-dev mailing list that is the relevant audience for this content).  Also provide a window of time for people who missed the meeting to read the notes and respond to them before making a decision about a topic (so a discussion at a TST meeting could propose a decision and then after feedback on the list the decision could be formalized).

• Look into etherpad as way to do collaborative note taking

• Put more ideas for how to increase transparency here

We need to have better documentation and review technical procedures

We gathered recommendations on this topic through a TST meeting, multiple CST meetings, blog post, Twitter and mailing list discussion.

• Reorganize wiki content structure and create owners for each section responsible for that content

• Build up a documentation community through community calls, docs mailing list, docs Slack channel, etc.

• Make better use of Confluence wiki tool (for instance, use tags for pages that need edits so it is easy to have list of pages to work on)
• Add documentation check as requirement of code review process

• Have section on wiki showing new edits

• Hackathon type events on wiki each quarter

• Prioritize creating an API Guide for the wiki

• Create a user guide

• Can documentation be baked into the code base somehow -- coding and documenting feel separate today (bonus: docs are versioned along with code) - is this a better way for people to consume though?

• Find way to connect information – content is often there but fragmented and spread across YouTube, wiki, Slack, etc

• Put more ideas for how to improve documentation and review technical procedures here

We need to avoid ON.Lab staff becoming a bottleneck

We gathered recommendations on this topic through a TST meeting, multiple CST meetings, blog post, Twitter and mailing list discussion.

• Improve and expand the module ownership system which has already helped remove ON.Lab staff from code review bottlenecks and provide more incentives around reviewing to encourage people to do more of it

• Launch the ONOS Ambassadors program to identify people who can run, organize and speak at events that have required staff presence in the past

• Create a formal projects lifecycle process to allow anyone to create a project independently without needing TST’s involvement

• Put more ideas for how to avoid having ON.Lab become a bottleneck here

We need to reduce barriers to contribution

We gathered recommendations on this topic through a TST meeting, multiple CST meetings, blog post, Twitter and mailing list discussion.

• Review the times of all community meetings to make sure communities around the world can attend.  For instance, the TST meeting at 3 pacific is too late for Europe and too early for Asia – perhaps the meeting could alternate between an earlier time (maybe 10 pacific) and a later time (perhaps 4 or 5 pacific) so that community members in Europe and Asia have a chance to attend

• Create an onboarding experience so people don’t have to figure out so much on their own

• Create a mentorship system to share information that is tacit

• Create a system of asynchronous decision making so people who miss a call still have a chance to have a voice in decisions

• Put testing in place to make sure existing processes are working (for example, current registration system breaks regularly and we don't always detect failures quickly)

• Put more ideas for how to reduce barriers to contribution here