My 2 cents… >>>> 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.
- This is an very good practice to follow and it would help to keep project healthy. This will also helps to stop committers to approve the code by them self. We follow this practice in OpenStack community on every commit we merge into git repository. - Systematically we could make the onap gerrit to address it. >>> General Guidelines: Currently we are trying to keep the one as committer, only if (s)he contributed seed code either in ONAP or Open-O. But, I feel that we should also take consideration of the subject matter expertise , who are 1. already having good working experience in technology and domains 2. already worked on similar projects in related/dependent communities like OpenStack, OPNFV as committer/active-contributor. 3. willing to play the committer role from different companies who were neither part of Open-O nor ONAP, (satisfying #1 but not #2) it would open opportunity to those, on trust basis and is good for community This would help to bring authorative 3rd eye to review the code from different perspective, which is good for keeping project in right/neutral path, while seed code contributors look at the code only from their perspective. Regards Kanagaraj M *************************************************************************************** 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！************************************************************************************** *************************************************************************************** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! *************************************************************************************** From: [email protected] [mailto:[email protected]] On Behalf Of Phil Robb Sent: Monday, May 15, 2017 8:07 PM To: onap-tsc; [email protected] Subject: [onap-discuss] How to best populate Contributors and Committers in newly formed ONAP projects 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-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
