...

• Opportunity: Joining a brigade is a unique opportunity to work with the core engineering team and participate in work onsite at Menlo Park
• Recognition: The work of brigade members will be showcased widely with the community both online as well as at events, like at ONOS Build
• Experience: Taking part in a brigade is a great opportunity, especially for students, to get experience in network engineering and is a great stepping stone to possibly work at ON.Lab ONF or other member organizations
• Acceleration: Helping a brigade deliver a feature will get work that you care about into an official ONOS release much more quickly than it would without the brigade's efforts.
• Research and Development: A brigade can bring together researchers and engineers from both academia and industry to propose and develop new features and applications in the SDN/NVF domains or to model, measure, and evaluate performance of current implemented services.

...

• Build and Package Infrastructure 
  
• Deployments
• Dynamic configuration
• gRPC  
• GUI
   
• ISSU (In-Service Software Upgrades)
  
•  Lion (Localization/Internationalization)
• Orchestration
• P4
  
• Security & performance analysis  
  
• Teaching
  
• Virtualization

...

If you're interested in the work of any of these brigades, please take a look at that brigade's wiki page to learn more about what is happening, what help is needed and how to get in touch with the team.

Expectations

The brigade helps the community scale and take on work items. In using brigades as a work unit, the community is counting on them to execute to their plans successfully. We expect the leader and the brigade members to have the desire, motivation, and skills to make and MEET commitments to the community. Also, as part of the community, it is expected that brigades will engage with the release planning process and the sprint planning process. Specifically, we expect brigades to do the following in the different phases of the ONOS release cycle:

Planning

• The brigade lead will work with their team and the ONOS TST to define a high-level vision for their group's efforts and will document this on their brigade's wiki page.
   
• The expectation is that the lead will be working with their brigade to define a set of deliverables that the team can commit to delivering and this will be communicated in the release planning meeting.  The deliverables and requirements can come from many places in the community, or from the brigade itself. The community is counting on the brigade to deliver on its promises for the release.

Execution

• The brigade will keep a public location updated with work items and status so that the brigade's work is visible to the community (a JIRA dashboard, for example).
• The lead, or the lead's delegate, will participate actively in the brigade review meeting held once a month in order to work with other leads to solve problems and make their brigades and the brigade program better.
• If there are concerns about progress on committed deliverables or with any part of the brigade process, we expect leads to reach out and raise those concerns so that we can support you with addressing those.
• We expect that progress will be communicated in the regular sprint review meetings through creating a slide with relevant details about what progress has been made in the brigade over the sprint period.  Attending the meeting to talk over the slide is optional but encouraged.
  

Delivery

• The lead, or the lead's delegate, will participate in the release review meeting to show what the team accomplished for the release.  We expect relevant details to be captured in a slide.  We highly encourage that a brigade does a demo at this meeting to showcase their efforts to the community.
  

Roles, Recommendations and Requirements

...

Mentorship is vital in an open source community because so much information and knowledge is often not written down or documented.  Mentors focus on leveling up brigade members so they have the skills to be successful.  For brigades where there are leads or members who do not have easy access to the ON.Lab ONF offices in Menlo Park, mentorship is also crucial since you do not have the ability to easily interact with and ask questions of core team members based there.  Because of that, we encourage all brigades that are not lead by an ON.Lab staff ONF staff member to have a mentor who can support them, answer questions and get them unstuck when they are blocked.  Mentors can be ON.Lab ONF staff members, TST members, module owners or anyone else who has deep knowledge to share about the work the brigade is doing.

Members

Anyone who is interested in participating in a brigade can join as a member and they will be asked to identify specific tasks related to that brigade's efforts that they will take on.  They are responsible for participating in the brigade's planning and for communicating their progress with their fellow brigade members.

Product Owners

The product owner makes sure the work of the brigade is relevant to the operator. As such, the product owner usually comes from an operator environment (AT&T, Verizon, etc..) and they have a PoC, Lab Trial, or Field Trial that has been selected by the use case steering team. The person could also come from a vendor involved in a PoC, lab trial, or field trial. It is similar to the role as defined in agile scrum. In short, they make sure the features are defined from the end user perspective, and they make sure that work is done in priority order. The product owner provides "pull" for features from the team - helping to bring the work into use in the network. One can find more information on the web about the role of a product owner. One such page is here.

Meetings

Brigade leads and members come from around the world and we recognize that it is impossible to schedule meetings that will work for everyone in every time zone.  Because of this we are sensitive to asking people to attend meetings and we've tried to minimize brigade-related calls.  We strongly encourage brigades to participate in the regular sprint and release reviews however since it is important to coordinate your efforts with others in the project and it is a great opportunity to get the recognition and credit you deserve.  If a lead can't join the meetings, please find someone else on your brigade that can make the call.  You can find the meeting details on the ONOS community calendar.  For other meetings, you and your brigade can decide if and when to schedule team meetings.

Brigade Leads Mailing List

If you are leading a brigade or acting as a mentor, please take an active role on the Brigade Leads mailing list.  This list is for leads and mentors of active ONOS and CORD brigades.  Discussions will focus on discussing issues, asking questions and sharing tips about running a successful brigade.  You will benefit from learning about what has worked well for other brigades and other leads can learn about the tips and suggestions you have from your experience.

Test Coverage

Test Coverage is an important aspect for stability of ONOS.  Test Coverage includes Unit Tests and System Tests. 

...

System Test Coverage includes delivery of detailed test plans and shared with the team for reviews.  Critical and Major functional test scenarios are to be targeted for automation.  Automated tests/scripts need to be submitted into the common repository.  By committing test cases to a common repo it helps the community/users to scale the tests in future.  All test cases that are automated need to be run before and after code merges into the mainstream. Once code is committed to the mainstream, automated test scripts need to be integrated to jenkins QA jobs for continuous regression of the features.

ON.Lab ONF test engineer(s) will collaborate with the testers in the brigade and guide them through the test coverage procedures.  Testers on the brigade team can also take advantage of the existing automation framework and tools that ON.Lab uses ONF uses for automated tests.

Refer to System Testing Guide for more details.

Visualization of Roles and Process

...