Both projects, devon and OASP, are 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.
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 the GUI Tool "GitHub Desktop" a user can easily manage project files. There are private and public repositories. Public ones (like OASP) can be accessed by everyone, private repositories (like devon) require access permissions.
The devon and OASP 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.
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.
In total, there are three GitHub projects regarding OASP and devon:
-
Repository used for work on the guide - Similar to the according devon repository devon-guide
-
The official Open Application Standard Platform project repository. Usually, two main branches exist:
-
develop
This branch contains software in the state of being in development.
-
master
This branch contains software in release state.
-
-
This is a private repository. You have to be logged in and have permissions to access the project and its repositories. Similar to OASP, there are usually two branches:
-
develop
-
master
-
In order to contribute to our projects, developers must follow the following development guidelines. Other sources about contributing to devon/OASP:
Every project must include the following files in order to establish the contributing rules and facilitate the process:
-
CONTRIBUTING.asciidocthat establishes the specific guidelines of contributing in a project repository. -
CODE_OF_CONDUCT.asciidocmandatory to contribute. -
ISSUE_TEMPLATE.asciidocthat defines the appropriated way to submit an issue in a project repository. -
PULL_REQUEST_TEMPLATE.asciidocthat specifies the rules in order to submit a pull request in a project repository.
This files should be included at the root folder or in a docs folder. This repository is a good resource to find the perfect templates for issues and pull requests that fit in your repository.
-
Use the issue tracker to check whether the issue you would like to be working on exists. Otherwise create a new issue.
Figure 1. 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 Devon 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:
oasp/oasp4j#1: added REST service for tablemanagementNote: 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 bugThe 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.
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.
Figure 2. 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.
Figure 3. If Travis fails to build a project, it’ll post the results directly to the pull requestCombining these two possibilities should accelerate the reviewing process of pull requests.
