DCAE Committer Guidelines

In addition to the guidelines specified Committer Best Practices, all DCAE committers are expected to look at these areas before merging a patch. If any item is not followed, you should reply with a -1. Also add comments in appropriate places within the code.

Check the Commitment Message:

is the JIRA ticket issue related to this fix?
does either the issue or the commitment message properly describe what is being changed and why?

Check the License Blocks and Copyright Lines on all code and documentation files

is there a LICENSE.txt file?
All code modules should have comments at the beginning that look like:

# ================================================================================
# Copyright (c) 2017-2020 Company1. All rights reserved.
# Copyright (c) 2020 Company2. All rights reserved.
# Copyright (c) 2020 Company3. All rights reserved.
# ================================================================================
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
# ============LICENSE_END=========================================================

All documentation files should have comments at the beginning that look like:

.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. Copyright (c) 2017-2020 Company1. All rights reserved.

Does it mention the current year for the company doing the modification?
Note that there is no separator between Copyright lines by different companies.
Note that when a company updates code that was previously copyrighted by them, the date range should be extended as shown.
There is no alternate wording for the copyright lines, such as "modifications copyright"

Check for comments in all new code

We should improve the documentation in the code whenever possible. At a minimum, NEW code should be documented.

javadocs, pydocs format preferred on all public methods and classes

Check the code

Most importantly, does it actually fix what the commitment message says should be fixed?
Verify against ONAP code standards.
- Java style is specified here, which points to the Google Style Guide repo.
- Javascript code should meet the similar Javascript Google Style Guide, except for the number of characters in one line of code is not restricted.
- Python code should similarly match the Python Google Style Guide.

Check whether the version number should be updated

if there is any new feature/enhancement
- the patch version should be bumped

if a change is a bugfix on a previously merged patch, AND if that previous version is not already released
- then version change is optional
different repos need to have the version number expressed in multiple places
- document those . . . TBD

Were there any -1 on previous patches by another committer or the PTL?

This is a FULL STOP.
Please DO NOT merge the code until:
- that other committer has given at least a subsequent +1 or
- the PTL says it is okay to +2 anyway (which would be very rare)