Versions Compared

Old Version 3

changes.mady.by.user Michael O'Brien

Saved on

compared with

New Version 4

changes.mady.by.user Michael O'Brien

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

ONAP membes seeking promotion to committer status should demonstrate the following abilities and behaviours before being considered for promotion.  Ideally the individual has been participating in the community and several projects including the one they are seeking promotion to.  Contributors can perform 95% of the duties of a formal committer including the following which would be expected from both contributors and committers.

  • Proactive - do not wait to be part of a epic/story/task or wait to be part of a review, or wait to bring forward build/design issues, or wait to bring new capabilities to the project and any other members of ONAP pushing or pulling from your component
  • Gerrit involvment - putting up reviews of their own, reviewing other reviews of contributors/committers
  • JIRA involvement - including one or more of raising, reviewing, commenting, testing, linking, attaching to, answering questions on, closing JIRAs
  • Confluence involinvolvement - writing/editing/reviewing/answering-on wiki pages around their projects, building in general
  • Git involvement - being able to clone, build, patch, commit and run the code in their project and ideally any of the north or southbound dependend projects
  • Knowledge of the architecture and API of the project - ideally across ONAP
  • Participation in onap-discuss work including helping with issues, raising issues
  • Participation in the weekly project meeting
  • Participation in pre-release blitzes
  • Integration ability - the developer should be able to bring up the entire ONAP deployment either in OOM or HEAT to be able to E2E test their particular component and any flows involving it

Best Practices

  • Committers should not "self merge" their own changes
    • Committers should add other committers as reviewers and have at least 2 Committers show approval (with a +1). The first reviewing committer will +1, the second reviewing committer will +2.
    • One exception to the rule is self merging critical changes required to unblock broken builds.
  • Committers should only merge proposed changes from contributors after at least 2 (+1) reviews.
  • Committers should remove themselves from a review under the following circumstances: 
    • Committer has been added as a reviewer to a change they do not feel comfortable reviewing
    • Committer anticipates a lack of time to review within 1 week 
  • Committers who remove themselves should leave a short comment in the change explaining to the owner the reason for removal
    • This allows owners opportunity to find others willing to review (or to make changes to significantly simplify or further document change)
  • Committers should aim to review all pending changes which have passed verify, have no merge conflicts or (-1) or (-2) reviews in a timely manner. 
  • Committers are welcome to ignore pending changes which do not pass verify, have merge conflicts or have been reviewed (-1) or (-2).
  • Committers should occasionally review the list of all old changes (To be defined). Owners of old changes should be contacted to ascertain if the change can be abandoned. If change owners do not respond or respond that the change has been abandoned, it should be abandoned.

...