Skip to content
This repository has been archived by the owner on Jul 25, 2018. It is now read-only.

Dev DoD and Style

Jump to bottom
Michael edited this page Mar 7, 2018 · 16 revisions

The definition of done helps to set a common understanding for solving a ticket.

Definition of done policy

  • Review points should involve one person from another angle (not just the person you were sitting together with anyways)
  • Limit items in review to 5, try to coordinate

Using Github assignments to issues or pull requests

  • Open review items require conversation

Definition of done items

  • File headers in file OK

    • EPL-1.0 license header
    • Or, if the file is too small, configuration file: license note (see code style)
    • Copyright and author

  • Avoid (serious) compiler warnings

    • Squash your commits into one or more logical units of work. No dozens of hourly/daily commits in your pull request, please

    • Rebase onto current master so that a fast forward merge is possible

    • That means that merge to master is prepared

    • use conventional changelog for commit messages: https://conventionalcommits.org/

      Dev-Semantic-Commits

  • No breaking test

    • Unit testing as it is already present
    • You have more - use them!

  • New test

    • For new / added functionality

  • Documentation

    • in the Githuib Wiki-Section, if you have done something new
    • At least a technical note for newly added functionality

  • Commit style

    • try to squash commits. In the ideal case, a feature is contained in one commit.
    • try to use conventional changelog for commit messages.

  • Review

    • Code style, not really formatting, but issues like style attributes in HTML tags or exception handling useful
    • DoD items reached
    • Design / architecture issues
    • Community contribution suitability
    • Issue coverage (does it actually solve the problem?)
    • Explicitly:
review-by:email@domain.com

and

tested-by:email@domain.com

Licensing and file header

All files contributed require headers - this will ensure the license and copyright clearing at the end. Also, all contributions must have the same license as the original source.

If a file has relevant functionality

/*
 * Copyright COPYRIGHT HOLDER, 2017.
 * Copyright NEXT COPYRIGHT HOLDER, 2017.
 * Part of the SW360 Portal Project.
 *
 * SPDX-License-Identifier: EPL-1.0
 *
 * All rights reserved. This program and the accompanying materials
 * are made available under the terms of the Eclipse Public License v1.0
 * which accompanies this distribution, and is available at
 * http://www.eclipse.org/legal/epl-v10.html
 */

(please adapt comment characters usage)

For small files such as property files, configuration files or standard XML files:

# Copyright <COPYRIGHT_HOLDER>, <YEAR>. Part of the SW360 Portal Project.
#
# All rights reserved. This configuration file is provided to you under the
# terms and conditions of the Eclipse Distribution License v1.0 which
# accompanies this distribution, and is available at
# http://www.eclipse.org/org/documents/edl-v10.php

Code style

Just use the standard Java formatting rules of your IDE and do not reformat code from others because you like to correct formatting of other's code.

Exception handling

Clone this wiki locally