Hello ONAP Development Community: I wanted to kick off a thread where we can discuss the best way to populate contributors, committers, and Project Technical Leads (PTLs) as we are forming the first ONAP project teams over the next few weeks. For consistency across projects and the formation of a healthy development ecosystem, it is important that we all have a common understanding of the roles and responsibilities of each of these participants in our community. There is no "one way" to do this so please do not consider this email as an edict to be blindly followed. Instead, I'd like to provide some best-practices gathered over the years, then for us to discuss, then come to consensus on how we will populate these roles.
First the definitions: Contributor: Anyone who wants to participate in the project. This can be providing input on the email list, contributing a bug fix, contributing code for a new feature, writing test case or documentation, etc. Like everyone in the project, these people always have a voice and are welcome to provide their thoughts and insights in any technical discussion within the project. Committer: A contributor that has the authority, and responsibility to submit changes to the ONAP software repository. Typical characteristics of a Committer are: 1) Deep expertise in the code base over which they are committers 2) Time dedicated to reviewing code contributions made by other contributors 3) Knowledge and understanding of the overall development activities occurring within the project - this is important so that the review of new code is taken in the context of the overall development for the project. 4) Knowledge and understanding of other, interdependent projects within ONAP and how contributions to this project affect work being done elsewhere by others. The Committers on a project will review each code contribution made by the Contributors, and other Committers on the project. Often, a Committer will need to enter into a dialog with a Contributor to have them make changes to the contribution to better fit the functional or structural makeup of the existing codebase. It is preferable to have at least 2 Committers show approval (with a +1) for a contribution before it is accepted into the repository. It is also a best practice to never have a Committer review and/or approve their own contribution into the repository. Project Technical Lead (PTL): The PTL is a committer who is the one point of contact responsible for representing the project to the rest of the ONAP community. For projects that become part of any given release, the PTL is responsible for reporting milestone status and release readiness to the rest of the community. The PTL for each project is elected by the other committers within the project. Please note that it is very common for individuals to be a committer on one project, and an contributor on another. However, there is nothing stopping an individual from being a committer on multiple projects. Also, it is rare, but not unheard of, that an individual can be a PTL on more than one project. General Guidelines: When forming projects such as ONAP where there is a great deal of initial (seed) code, it is helpful to establish some common guidelines for projects to follow when building their initial contributor, committer, and PTL lists. Here are some general best practices. - Identify yourself as a Contributor on a project proposal if you believe that you have the time and ability to contribute to the development of the project. One of the goals of every project within ONAP is to have a diverse set of contributors working on the project. This shows that the project has broad interest within the community and that the development of the project will reflect a varied set of end user use-cases, and requirements. Please do not put your name down if you do not have the time or ability to participate. - Identify yourself as a Committer on the project only if you have significant expertise in the seed-code that is already present in the ONAP code repository. The one exception to this rule is in the event that the first activity of the project is to bring in significant code or functionality that exists in another code base. In such situations it may be helpful to have a Committer position(s) for individuals with expertise in the other code base to aid in the review of such code as it is contributed to the existing seed-code in the repository. I would suggest that the Committers with deep expertise in the seed-code within the repository determine how best to (or if to) include experts in other codebases to participate as Committers within the project. If help is needed for this particular task I am happy to help facilitate the discussion on a project-by-project basis. - There should be enough Committers on a project to effectively perform the reviews on all of the contributions in a timely manner. If there are not, then contributions will stagnate waiting for review to the frustration of the Contributors on the project. Conversely, having far more Committers on a project than contributions to review will mean that many Committers will be in-active simply due to no work load. The "right" number of initial Committers is project dependent, but a good rule of thumb is to start in the 3 to 6 range, and expand beyond that if needed or desired. - It is common for individuals to identify themselves as initial Committers on the project then realize that they did not have the time, ability, or expertise to properly perform the role. Please self-evaluate your capabilities for the role before suggesting yourself for it. Similarly, ONAP project Committers and PTLs should review their committer list on a periodic basis (quarterly or semi-annually) to cull the Committer list of in-active Committers. - Individuals who initially identify themselves as Contributors on a project can be promoted to Committer by showing their expertise in the code base through quality code contributions and technical insights on the mailing lists, irc channels, bugzilla entries, etc. Please note that active Contributors on a project can have significant influence in the project from the code and comments they make. - Given that seed-code often comes from a single, or small number of companies, it is likely that many projects will have initial Committers from a single, or small number of companies. In those special situations, the Committers for the project have additional responsibilities: 1) These Committers should be actively searching for Contributors in their project that show the aptitude and interest to become Committers and work to mentor these individuals to become Committers on the project as quickly as possible. 2) These Committers must take special care to socialize and receive feedback on any significant change to the code base that they are considering. It is important that the Committers of a project reflect the goals and interests of all community members, not just the goals and interests of their employer. - Once a project has been formed and the initial list of Committers has been identified and agreed upon, those Committers will need to elect a PTL to serve as the single point-of-contact for the project to the rest of the community. Please provide your additional thoughts to the ones I've provided above. It will be helpful to all if we can come to consensus on how best to initially populate the ONAP projects so that there is a general understanding of the criteria used and it's consistent application across all projects. Again, our goal should be to get the right set of competent resources in place to begin with, and have the expectation that new Committers will be promoted within the projects shortly after we begin development in earnest. Best, Phil. -- Phil Robb Executive Director, OpenDaylight Project VP Operations - Networking & Orchestration, The Linux Foundation (O) 970-229-5949 (M) 970-420-4292 Skype: Phil.Robb
_______________________________________________ ONAP-TSC mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-tsc
