Skip to content
This repository has been archived by the owner on Nov 23, 2021. It is now read-only.

fix ant configuration #132

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
54 changes: 54 additions & 0 deletions CODE_OF_CONDUCT.asciidoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
:toc: macro
toc::[]

:doctype: book
:reproducible:
:source-highlighter: rouge
:listing-caption: Listing

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.

== Contributor Covenant Code of Conduct

=== Our Pledge

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.

=== Our Standards

Examples of behavior that contributes to creating a positive environment include:

* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members

Examples of unacceptable behavior by participants include:

* The use of sexualized language or imagery and unwelcome sexual attention or advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting

=== Our Responsibilities

Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.

Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.

=== Scope

This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.

=== Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at *[INSERT PRODUCT OWNER EMAIL ADDRESS]*. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.

Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.

=== Attribution

This Code of Conduct is adapted from the https://www.contributor-covenant.org[Contributor Covenant], version 1.4,
available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
159 changes: 159 additions & 0 deletions CONTRIBUTING_GUIDE.asciidoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,159 @@
:toc: macro
toc::[]

:doctype: book
:reproducible:
:source-highlighter: rouge
:listing-caption: Listing

== Code Contributions

=== Notes on Code Contributions

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 <<Contributor Covenant Code of Conduct,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`.

=== 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 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.

==== Creating a new user account

The devon and OASP projects use GitHub as hosting service. Therefore you'll need an account to allow collaboration. Visit https://github.com/join?source=header-home[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.

==== Git Basics

An in-depth documentation on basic Git syntax and usage can be found on the https://git-scm.com/docs[official Git homepage]. Another helpful and easy to follow instruction can be found http://rogerdudler.github.io/git-guide/[here].

=== Structure of our projects

In total, there are three GitHub projects regarding OASP and devon:

* link:https://github.com/oasp-forge[*oasp-forge*]
+
Repository used for work on the guide - Similar to the according devon repository link:https://github.com/devonfw/devon-guide/wiki[*devon-guide*]
* link:https://github.com/oasp/[*oasp*]
+
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.

* link:https://github.com/devonfw/[*devonfw*]
+
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*

=== Contributing to our projects

In order to contribute to our projects, developers must follow the following <<Development Guidelines,development guidelines>>. Other sources about contributing to devon/OASP:

* https://github.com/oasp/oasp4j/wiki/oasp-code-contributions[OASP code contributions]
* https://github.com/oasp/oasp4j/wiki/oasp-documentation[OASP documentation]
* https://troom.capgemini.com/sites/vcc/devon/collaboration.aspx[Devon collaboration]

*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.

This files should be included at the root folder or in a `docs` folder. https://github.com/stevemao/github-issue-templates[This repository] is a good resource to find the perfect templates for issues and pull requests that fit in your repository.

==== Process of contributing code to the devon/OASP projects

* Use the issue tracker to check whether the issue you would like to be working on exists. Otherwise create a new issue.
+
.Using GitHub's issue tracker
image::images/contributing/issue_list.PNG[Issue list, width="450", link="images/contributing/issue_list.PNG"]

* 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 https://www.yammer.com/capgemini.com/#/threads/inGroup?type=in_group&feedId=5030942&view=all[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,Working with forked repositories>> document to learn all about this topic.
** Check out the develop branch
+
[source, bash]
----
git checkout develop-x.y.z
----
** Create a new branch
+
[source, bash]
----
git checkout -b myBranchName
----
* Apply your modifications according to the https://github.com/oasp/oasp4j/wiki/coding-conventions[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:
+
[source]
----
#<issueId>: <change description>
----

** When working on multiple different repositories, the actual repository name of the change should also be declared in the commit message:
+

[source]
----
<project>/<repository>#<issueId>: <change description>
----
+
For example:
+
[source]
----
oasp/oasp4j#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.:
+
[source]
----
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_.

=== Reviewing Pull Requests

Detailed information about revieweing can be found on the https://help.github.com/articles/reviewing-changes-in-pull-requests/[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.
+
.People can add comments to pull requests and suggest further changes
image::images/contributing/pr_commenting.PNG[Commenting on pull requests, width="450", link="images/contributing/pr_commenting.PNG"]

* *CI based reviews*
+
CI Systems like https://jenkins.io/[Jenkins] or https://travis-ci.org/[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.
+
.If Travis fails to build a project, it'll post the results directly to the pull request
image::images/contributing/travis_failure.png[Travis failed to build, width="450", link="images/contributing/travis_failure.png"]
+
Combining these two possibilities should accelerate the reviewing process of pull requests.
13 changes: 13 additions & 0 deletions ISSUE_TEMPLATE.asciidoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
Category: Bug or enhancement

Severity: Low , Medium, High, Critical

Expected behaviour (In case of bug)

Actual/current behaviour (In case of bug)

Steps to reproduce (In case of bug)

Description of issue / expected enhacement /Comments

Your environment - windows/Linux, Devonfw version , component
Loading