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:

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
    • Next step: Prioritize ONOS-4461 in upcoming release planning meeting
  • 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).
    • Next step: This is happening now for key meetings including the TST and CST calls.  For next steps we need to make sure we do this consistently going forward.

  • Look into etherpad as way to do collaborative note taking

    • Next step: We can try out the free workopen.org etherpad site to see how we like it

  • 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

    • Next step: Work on this is happening in the open documentation calls.  This item will be updated when the restructuring is done and the owners are picked for each section

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

    • Next step: This work is happening – a regular open community call was started recently, an onos-doc mailing list was created and a docs Slack channel too.
  • 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

    • Next step: This does exist on the Wiki home page although we could promote it more so people are aware of it

  • 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

    • Next step: Prioritize ONOS-4201 in upcoming release planning meeting

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

    • Next step: Launch is planned for July

  • 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
    • Next steps: The TST meeting times have changed and it now alternates between early pacific time and late pacific time to be more friendly to European and Asian community members.  Other meetings can be moved as needed, although there is no ideal solution to the time zone scheduling issue – we'll also need to move to more of an asynchronous decision making model (see below) to fully reduce time zone barriers.

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

  • Create a mentorship system

    • Next steps: Proposal to TST to expand role of module owners to include mentoring as well as code reviewer.  Launching Ambassador program will also officially designate people to be community mentors

  • Create a system of asynchronous decision making so people who miss a call still have a chance to have a voice in decisions (for exampe, a TST meeting can discuss and propose a decision and then after posting about this to the mailing list and allowing time for feedback the decision could then be formalized).

  • 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
  • No labels