Jump to: navigation, search

Difference between revisions of "NeutronCore"

m
 
Line 18: Line 18:
 
* Participation in neutron related design summit sessions at the summits.
 
* Participation in neutron related design summit sessions at the summits.
  
In addition to the above, code reviews are a critical. Neutron follows the documented OpenStack [https://wiki.openstack.org/wiki/ReviewChecklist code review guidelines]. We encourage all people to review neutron patches, but cores are required to maintain a level of review numbers relatively close to other cores. There are no hard statistics around code review numbers, but in general we use 30, 60, and 90 day stats when examining review stats:
+
In addition to the above, code reviews are a critical. Neutron follows the documented OpenStack [https://wiki.openstack.org/wiki/ReviewChecklist code review guidelines]. We encourage all people to review neutron patches, but cores are required to maintain a level of review numbers relatively close to other cores. There are no hard statistics around code review numbers, but in general we use 30, 60, 90, and 180 day stats when examining review stats. The 180 day stats in particular show a good cross section of half a year of reviews.
 
* http://stackalytics.com/report/contribution/neutron/30
 
* http://stackalytics.com/report/contribution/neutron/30
 
* http://stackalytics.com/report/contribution/neutron/60
 
* http://stackalytics.com/report/contribution/neutron/60
 
* http://stackalytics.com/report/contribution/neutron/90
 
* http://stackalytics.com/report/contribution/neutron/90
 +
* http://stackalytics.com/report/contribution/neutron/180
  
 
There are soft-touch items around being a core as well. Gaining trust with the existing core team is important. Being able to work together with the existing team is critical as well. Being a core means spending a significant amount of time with the existing core team on IRC, the mailing list, and reviews. Ensuring you participate and engage here is critical to becoming a core.
 
There are soft-touch items around being a core as well. Gaining trust with the existing core team is important. Being able to work together with the existing team is critical as well. Being a core means spending a significant amount of time with the existing core team on IRC, the mailing list, and reviews. Ensuring you participate and engage here is critical to becoming a core.

Latest revision as of 15:39, 2 December 2014

The Neutron Core Team is responsible for merging changes into the following repositories:

While everyone is encouraged to review changes for these repositories, neutron-core has the ability to +2/-2, as well as +A changes to these repositories.

Adding or Removing Members

A new member to neutron-core may be proposed at any time to the openstack-dev mailing list. Typically the PTL will propose a new member after discussions with the core team. Once a proposal has been made, five existing neutron-core members must respond to the email with a +1. Another neutron-core member can vote -1 to veto the nomination of the proposed core team member.

The PTL may remove a member from neutron-core at any time. Typically when a member has decreased their involvement with the project through a drop in reviews and participation in general project development, the PTL will propose their removal and remove them. Members who have previously been core may be fast-tracked back into core if their involvement picks back up.

Membership Expectations

Members of neutron-core have the following expectations:

  • Reasonable attendance at the weekly Neutron meeting on IRC.
  • Participation in neutron discussions on the mailing list, as well as in-channel in #openstack-neutron.
  • Participation in neutron related design summit sessions at the summits.

In addition to the above, code reviews are a critical. Neutron follows the documented OpenStack code review guidelines. We encourage all people to review neutron patches, but cores are required to maintain a level of review numbers relatively close to other cores. There are no hard statistics around code review numbers, but in general we use 30, 60, 90, and 180 day stats when examining review stats. The 180 day stats in particular show a good cross section of half a year of reviews.

There are soft-touch items around being a core as well. Gaining trust with the existing core team is important. Being able to work together with the existing team is critical as well. Being a core means spending a significant amount of time with the existing core team on IRC, the mailing list, and reviews. Ensuring you participate and engage here is critical to becoming a core.