59. Code Contributions

Moved here. This document will be removed in the future.

59.1. Notes on Code Contributions

devonfw platform is intended to be easy to contribute to. One service allowing such simplicity is GitHub was therefore selected as preferred collaboration platform.

In order to contribute code, git and GitHub specific pull-requests are being used.

It is mandatory to follow the code of conduct that must be present in the root of every OSS or private project as CODE_OF_CONDUCT.asciidoc or CODE_OF_CONDUCT.md.

59.2. Introduction to Git and GitHub

Git is a version control system used for a coordinated and versioned collaboration of computer files. It enables a project to be easily worked on by multiple developers and contributors.

GitHub is an online repository used by deonvfw and OASP in order to host the corresponding files. Using the command line tool or any GUI Tool as "GitHub Desktop", "Fork" or "Atlassian SourceTree" a user can easily manage project files. There are private and public repositories. Public ones can be accessed by everyone, private repositories require access permissions.

59.2.1. Creating a new user account

The devonfw projects use GitHub as hosting service. Therefore you’ll need an account to allow collaboration. Visit this page to create a new account. If available, use your CORP username as GitHub username and your CORP email address.

A GitHub account is essential for contributing code and gaining permissions to access private repositories.

59.2.2. Git Basics

An in-depth documentation on basic Git syntax and usage can be found on the official Git homepage. Another helpful and easy to follow instruction can be found here.

59.3. Structure of our projects

In total, there are three GitHub organizations regarding devonfw:

  • devonfw-forge

    Repository organization used for work on incubators and other research projects.

  • devonfw

    The official devonfw Platform project repository. Usually, two main branches exist inside each repository:

    • develop

      This branch contains software in the state of being in development.

    • master

      This branch contains software in release state.

59.4. Contributing to our projects

In order to contribute to our projects, developers must follow the following development guidelines. Other sources about contributing to devonfw:

Every project must include the following files in order to establish the contributing rules and facilitate the process:

  • CONTRIBUTING.asciidoc that establishes the specific guidelines of contributing in a project repository.

  • CODE_OF_CONDUCT.asciidoc mandatory to contribute.

  • ISSUE_TEMPLATE.asciidoc that defines the appropriated way to submit an issue in a project repository.

  • PULL_REQUEST_TEMPLATE.asciidoc that specifies the rules in order to submit a pull request in a project repository.

Important
This files must be included at the root folder or the the issues and pull request templates inside a .github folder.

This repository is a good resource to find the perfect templates for issues and pull requests that fit in your repository.

59.4.1. Process of contributing code to the devonfw projects

  • Use the issue tracker to check whether the issue you would like to be working on exists. Otherwise create a new issue.

    Issue list
    Figure 105. Using GitHub’s issue tracker
  • Before making more complex changes you should probably notify the community. The worst case would be you investing time and effort into something that’ll be later rejected. Oftentimes the devonfw Community on Yammer will have the right answer.

  • Assign yourself to the issue you would like to work on. If a member was already assigned to your preferred issue, get in contact to contribute to the same issue.

  • Fork the desired repository to your corporate GitHub account. Afterwards you’ll have your own copy of the repository you’d like to work on.

  • Create a new branch for your feature/bugfix. Check out the develop branch for the upcoming release. The following changes will afterwards be merged when the new version is released.

  • Please read the Working with forked repositories document to learn all about this topic.

    • Check out the develop branch

      git checkout develop-x.y.z
    • Create a new branch

      git checkout -b myBranchName
  • Apply your modifications according to the coding conventions to the newly created branch

  • Verify your changes to only include relevant and required changes.

  • Commit your changes locally

    • When commiting changes please follow this pattern for your commit message:

      #<issueId>: <change description>
    • When working on multiple different repositories, the actual repository name of the change should also be declared in the commit message:

      <project>/<repository>#<issueId>: <change description>

      For example:

      devonfw/devon4j#1: added REST service for tablemanagement

      Note: Starting directly with a # symbol will comment out the line when using the editor to insert a commit message. Instead, you should use a prefix like a space or simply typing "Issue". E.g.:

      Issue #4: Added some new feature, fixed some bug

      The language to be used for commit messages is English.

  • Push the changes to your Fork of the repository

  • After completing the issue/bugfix/feature, use the pull request function in GitHub. This feature allows other members to look over your branch, automated CI systems may test your changes and finally apply the changes to the corresponding branch (if no conflicts occur).

    Use the tab "Pull requests" and the button labeled "New pull request". Afterwards you can Choose different branches or forks above to discuss and review changes.

Note
Most of the devonfw projects contain a documents folder that includes the related documentation. It would be really interesting to add the documentation files of your new feature inside this pull request.
Bare in mind that, in case the changes have a big impact, the devonfw core team will request the necessary documentation in the pull request.

59.5. Reviewing Pull Requests

Detailed information about revieweing can be found on the official topic on GitHub Pull Requests.

There are two different methods to review Pull Requests:

  • Human based reviews

    Other project members are able to discuss the changes made in the pull request by having insight into changed files and file differences by commenting.

    Commenting on pull requests
    Figure 106. People can add comments to pull requests and suggest further changes
  • CI based reviews

    CI Systems like Jenkins or Travis.ci are able to listen for new pull requests on specified projects. As soon as the request was made, Travis for example checks out the to-be-merged branch and builds it. This enables an automated build which could even include testcases. Finally, the CI approves the pull requests if the build was built and tested successfully, otherwise it’ll let the project members know that something went wrong.

    Travis failed to build
    Figure 107. If Travis fails to build a project, it’ll post the results directly to the pull request

    Combining these two possibilities should accelerate the reviewing process of pull requests.

Important
This document is the Official Covenant Code of Conduct that must be present in every OASP or devonfw project at the root folder as CODE_OF_CONDUCT.asciidoc or CODE_OF_CONDUCT.md. Please, include this contents in your repository and the Product Owner email address in the right place below.
Last updated 2019-11-13 14:38:09 UTC