As the CORD community continues to grow it brings a challenge of how to coordinate a large group to make sure we’re all working toward a shared goal. One way to address this is to communicate clearly about our vision for CORD and invite people to work together on completing specific parts of that vision.
This is where the brigade model comes in — the idea is to create small teams around specific features that we want to ship in upcoming versions of CORD. This can help us connect with other people in the community who are excited about that feature and it gives that group a framework for working together.
Code for America has been successfully using brigades to build new tools that help with local civic issues all across the country. There are many best practices we can take from that experience to help us get moving quickly with this model in our community. If you’ve been involved in a Code for America brigade, we’d be very interested to hear your thoughts.
These are the active brigades that have formed and are welcoming new members. Please take a look at the page for each brigade to find out more about how to get started.
Concepts for new brigades are being developed and the ideas are maturing on the wiki. Please feel free to take a look and add your thoughts to the following brigade concepts.
Thanks to the community members who have been involved in brigades that have completed their work. The following M-CORD brigades worked together to develop PoCs for MWC Americas in September 2017.
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.
If you chose to take part in or lead a brigade, we have some best practices and recommendations for you.
We've been running brigades in the ONOS community for a while and based on that we have some best practices and recommendations to share.
A brigade leader is someone who has enough bandwidth to devote to the project -- this doesn't necessarily need to be someone who has the most technical experience and non-technical people can lead. This role is more about coordinating the enthusiasm of brigade members and to keep progress moving forward by coordinating work weeks and regular project calls and also to make sure that brigade members aren't blocked and have what they need to be successful. Brigade leads should also keep their brigade wiki page updated with relevant information about their efforts (status, team members, communication channels, etc) and also share out news regularly with the community.
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 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 member to have a mentor who can support them, answer questions and get them unstuck when they are blocked. Mentors can be ON.Lab staff members, TST members, module owners or anyone else who has deep knowledge to share about the work the brigade is doing.
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.
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.
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 CORD community calendar. For other meetings, you and your brigade can decide if and when to schedule team meetings.
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 is an important aspect for stability of CORD. Test Coverage includes Unit Tests and System Tests.
For details on unit test coverage refer to Unit Test criteria and guidelines.
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 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 for automated tests.
Refer to System Testing Guide for more details.