The ONOS codebase is composed of different modules, and people have been given responsibilities over each of those modules. A "Module owner" is someone who can give a +2 review for a particular part of the codebase and submit code in that area.
Owners are responsible for maintaining the quality of contributions for their part of the codebase, and owners who are not performing their responsibilities will receive an initial warning and then may lose owner status. Benefits of being an owner include getting to influence the direction of the project through reviewing other people’s code, not having to wait to have their own code reviewed and receiving recognition for their expertise over the code.
A list of Module Owners is available on Gerrit (note that you need to be logged in to access this list). You can also find the list from the Gerrit UI: Projects -> List -> onos -> Module Owners.
A "super module owner" is someone who can give a +2 review for any part of the codebase (including new areas) and submit code into the repository. Super module owners should be module owners (or eligible for module ownership) in several distinct parts of the code base, as well as demonstrate a mastery of project-wide design, patterns, and objectives. This role is often called "committer" in other projects.
To be a good candidate for a Module Owner, you need to have a demonstrated proficiency with part of the ONOS codebase and a track record of code reviews. Members of the Technical Steering Team and existing Module Owners will regularly invite people to become new Module Owners.
Nominations for new Module Owners can also be submitted to the Technical Steering Team mailing list. A good nomination will include details about who the person is and what their experience is with a specific area of the codebase. Nominations are intended to start a conversation that results in a decision about granting or not granting ownership – anyone who isn't granted ownership initially is encouraged to gain more experience with code submission and code review in order to gain further mastery over the codebase.
Keep an eye on the big-picture as well as on the more cosmetic stuff. It’s harder to spot inefficiencies in the mid-level designs, but the good news is that as long as things are properly compartmentalized and not entangled (from the big picture), the mid-level stuff can be addressed individually if something less-than-ideal slips through. Please feel free to also provide feedback on other areas of code outside your designated area - all help is welcome - and conversely, if something falls in your area, but you’d like a second opinion, just +1 and make sure other reviewers are on the list. If you ever have any questions about what to do, please ask on the TST mailing list.
If you are interested in the code for the plugin, need to file a bug or want to help improve it, it is available here: https://github.com/bocon13/moduleowner