Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
There are several elements that a community needs in order to be healthy and effective -- clear communications, contribution pathways, community metrics, learning opportunities, recognition efforts, and a friendly environment. This document looks more closely at each of these and provides examples for what we could do for each of these areas for the ONOS community. This is intended to be a touchstone document for the Community Steering Committee to use to make sure any plans they make for the community fit with our beliefs about what makes for a healthy and effective open source project.
Clear Communications
Providing clear communications to people who want to get involved is vital to their chances of successfully contributing. We can make communications more clear by:
Making contribution information easier to find on the ONOS site and wiki
For example, information about how to contribute to documentation requires 4 clicks to get to from the project homepage and this could be surfaced so people could find this in 2 steps.
Fixing broken links on the website and wiki
For example, there are several broken links on the Beginner’s Guide to Contribution page -- a place where dead-ends can be very confusing for people who are new to the project.
Updating the project homepage with the project’s mission and a call to action to contribute
Understanding a project’s mission is an important part of why people chose to contribute. In fact, it is so key that Karl Fogel's book "Producing Open Source Software" has this advice: "This should be prominently placed on the front page, preferably right under the project's name."
Providing regular community content through a community blog
Healthy communications in an open community needs to be a two way channel and a community blog will let us share information about what we’re doing and will let people comment with ideas, feedback and suggestions to help us improve our plans
Contribution Pathways
Providing information about how someone can successfully get involved with each available contribution opportunity allows a project to scale since each contribution doesn’t have to be crafted in an ad-hoc way. We can create and improve contribution pathways by:
Optimizing existing pathways
For example, the Beginner's Guide to Contribution documentation includes several steps that are unnecessary and contain potential places where a new contributor could get stuck. We can audit this pathway and make this process easier for people to complete.
Creating new pathways that meet the needs of the community
The Technical Steering Committee has identified that there is currently a situation where there aren’t enough code reviewers, so we can architect a new pathway that will help us identify people who want to help with this task and will let them understand what steps they need to follow to be successful.
Promoting contribution opportunities more broadly online and in the software
Once you have a set of contribution pathways you need to let people know about them. There are ways we can be promoting these pathways better on the ONOS web properties and in the ONOS software itself. For example, there is information about how to contribute to Mozilla in the Firefox About dialog and there is information about how to contribute to web development embedded in the HTML of Mozilla’s websites.
Community Metrics
Providing visibility into what’s happening with the community is critical to understanding the needs of the people involved with the project and to understanding how efforts to strengthen the community are working. We can get the community metrics we need by:
Establishing community success goals
We should have a discussion to understand what a successful community looks like and what goals we can set (growth, diversity, retention, satisfaction, etc.) to measure our progress going forward.
Gathering data from the people in the community
Hearing directly from the people who have been contributing to the project or who have been trying to contribute will give us a lot of important insights into what is working and not working that can help us iterate on this community plan.
Gathering data from the tools we use
We are already collecting some data from our tools at stats.onosproject.org. We should audit what there’s and add more data that would give us insight into other aspects of the community. For instance, the current stats don’t provide information about Starter bugs on Jira so we don’t have a way to understand how the Coding contribution pathway is performing.
Learning Opportunities
Providing opportunities to learn will empower people who are excited about the project to gain the skills and experience needed to successfully find and complete contribution opportunities that are meaningful to them. We can expand opportunities for learning by:
Setting up an explicit mentoring framework for ON.Lab staff
ON.Lab staff are experts on ONOS and this expertise needs to be distributed broadly in order to have a successful. There is a great quote about how Mozilla was able to scale its community through mentoring: “As you are successful, the amount of stuff that comes in should be growing and you should be starting to feel uncomfortable. Like there are too many demands, there’s too much work, I can’t get it done. Too much work coming at you is a sign of success. The way to handle it though, especially at Mozilla where we have unlimited opportunity, is to take what you really understand well enough to explain and pass it on and empower other people to do things.”
Supporting staff to design their projects for participation
Just as it is important to give new community members the chance to learn how to contribute to the project, it is important for staff to understand best practices in how to work with the community in an effective way. All staff members should feel supported in their efforts to work with the community in a way that is effective for them and does not detract from their role.
Investigating the use of a train the trainer model to scale learning opportunities
As the community grows, the ability to distribute information broadly will require more effort since there will be more people in more different locations. If we can teach people to teach others, this could allow us to scale the availability of learning opportunities to stay in sync with the need for learning opportunities.
Recognition Efforts
Providing recognition to people who contribute is an essential element of any open source project. When done well recognition serves to deepen and extend relationships and when it is not done consistently people will feel unwanted and frustrated and will stop contributing. We can implement recognition efforts by:
Understanding what forms of recognition are important to the community
Different communities will find different ways of recognition to be meaningful to them. We shouldn’t assume that any one particular form of recognition will be meaningful to members of the ONOS community until we ask directly for this feedback through surveys and discussions.
Layering in recognition to contribution pathways
In order to scale recognition efforts, it can not be done in an ad hoc way. By adding recognition into contribution pathways we can create a repeatable way to ensure recognition is done. For instance, we may identify that when someone has their first patch checked in that they get a t-shirt and when they do their first review of someone else’s code they get a thank you note from someone on the Technical Steering Committee.
Automating the process where possible
In order for recognition efforts to scale, we must find ways to make the process less manual. For instance, in a small community it’s possible for someone to occasionally send out shirts to community members. In a large community another way is needed so that someone isn’t shipping shirts all the time, such as having a system to send out coupons to contributors to an online swag store so people can select and send shirts on their own.
Friendly Environment
Providing a friendly and welcoming environment will help maintain the initial enthusiasm people feel when entering a community and will help keep people engaged as they start to contribute. We can create a welcoming environment by:
Creating a code of conduct
It is important to define expectations of good conduct in the community and to provide clear steps for what someone can do who has questions, comments or concerns about behavior in the community.
Auditing settings and roles of communication tools
We should be providing an open door for people who want to join the community and the configuration of all our communication tools need to allow for this. Right now though this isn’t happening consistently -- for instance, it is difficult to join the discussion on Slack unless you have a specific email address, the mailing lists are not publicly accessible, and information on the wiki is pointing people to an empty IRC channel.
Making opportunities for people to meet in real life
There is no substitute for meeting other communities members in real life in order to create a feeling of connection to a project. We should look for ways to scale up opportunities for people to meet. To do this in a scalable way, events will need to be organized and run by a range of people in the community, including ON.Lab staff, partners and volunteers.
About the team
The technical steering team is responsible for all technical decisions in the project. They are responsible for the content and structure of the code base and for all technical priorities with respect to the code base. The ONOS chief architect is the team lead of the technical steering team.
Who's in the team
The following folks are in the team for 2015:
Thomas Vachuska, Team Lead
Ali Al-Shabibi - southbound maintainer
Madan Jampani - core maintainer
Brian O’Connor - northbound maintainer
Jonathan Hart - core networking
Contact Information
Drop the technical steering team an email if you have a technical or architectural topic to discuss or get guidance for. The email archive is available for browsing and review of past conversations.
Contributors who wish to collaborate on medium to large feature submissions, are encouraged to follow the suggested process outlined on the Contributing to the ONOS Codebase page.
...
The team will be meeting every week, 15:00-16:00 PST via Google hang-outs and Slack #tech-steering channel. The recurring meetings along with their proposed agendas and resulting meeting minutes will be published below (in reverse chronological order):
Standing Agenda Items:
- Community Acknowledgements (2 minutes) – Please feel free to update the wiki in advance with details about who you would like to acknowledge and why
Specific Discussion Topics:
| Date | Agenda |
|---|---|
| ??? |
|
| 2016/01/20 | |
| 2016/01/13 |
|
| 2016/01/06 |
|
| 2015/12/02 | |
| 2015/11/11 |
|
| 2015/11/04 |
|
| 2015/10/28 | Cancelled due to lack of prepared topics |
| 2015/10/21 |
|
| 2015/10/14 |
|
| 2015/10/07 |
|
| 2015/09/30 |
|
| 2015/06/24 |
|
| 2015/04/29 |
|
| 2015/04/15 |
|
| 2015/04/01 |
|
| 2015/02/18 |
|
| 2015/02/04 |
|
Suggested Discussion Topics
The following topics have been proposed, but currently lack an owner. Proposed owners are shown in parentheses.
- Publishing events to external event bus, e.g. Kafka, RabitMQ (David Bainbridge & Madan?)
- Should any internal ONOS event be candidate for this?
- Consider correctness issues in distributed environments
- Branches for use cases (Brian?
- What will we create branches for?
- What is their lifecycle?
- Where should other supporting code go?
- Packet layer Bandwidth Enforcement (Ali or Jono?)
- Will likely require a protocol capable of configuration i.e. OVS-DB or NETCONF
- Moving docs from Wiki to version control - which parts? (Ayaka?)
Deprecated Topics
Modeling services in the ONOS network graphCan we provide more abstract graphs that contain higher level objects?How are new devices modeled?
Intent ModelingHow should new intent types be introduced into the framework?
...