Skip to content
This repository was archived by the owner on Oct 30, 2019. It is now read-only.

Contribution Guidelines

Jump to bottom
brian-murray35 edited this page Aug 18, 2015 · 79 revisions

BUILD is composed of multiple modules, each of which have their own repository. This document describes how to make contributions to any of these modules.

We want to make it simple and rewarding to contribute to BUILD based on the following principles:

  • As easy and transparent as possible to contribute.
  • Free, permanent, and public availability of the most up-to-date code base.
  • On-going maintenance and enhancement under a collaborative software development model.
  • High quality, consistent product performance and usability.
  • Commercial-friendly, mutually-assuring, standard license agreements.
  • Faithful adherence to evolving BUILD coding standards.
  • Respectful, honest, and technically-oriented communications throughout.
  • Security as the number one priority.

##What to Contribute?

You might know what you want to do. Otherwise consider contributing to BUILD in one or all of the following ways:

Contribute Bug Reports - contribute by reporting bugs you encountered when using Project BUILD.

When you report a bug, a code reviewer/committer on the core development team reviews it, approves it as a real bug, asks you for for more details, or closes it.

Approved bugs are either assigned to a committer in GitHub to fix or added to the backlog for future resolution. All bugs remain open until they are fixed. A bug that is about a real bug is closed as soon as the fix is committed. The closing comment explains which version(s) contain the fix. For more information on reporting bugs using the GitHub Issue Tracker of the relevant sub-project, see [Create Bug Reports](https://github.com/SAP/BUILD/wiki/Create Bug Reports).

Contribute Enhancements and Optimizations - you can contribute new features or enhancements, or contribute to already scheduled new features (with the label Please Contribute) in the sub-project GitHub Issue Tracker. Project Norman welcomes optimizations, new features and enhancements to existing features. However, we do not accept all feature requests. Therefore, to ensure that you are spending your time wisely, prior to coding your proposed enhancements we request that propose and discuss new features to core project developer first by creating an Issue labelled Feature Enhancement in the relevant sub-project GitHub Issue Tracker. For more information on proposing new features using the GitHub Issue Tracker of the relevant sub-project, see Using The GitHub Issue Tracker.

When a core developer responds, discuss the proposed enhancement with them. Once this discussion yields a shared consensus, you can confidently proceed and create the code. Furthermore, the developer might have some valuable hints and tips that save you a lot of time of and effort.However, before you do any work beyond conceptual, we recommend you post an Issue with the label User Story on the GitHub Issue Tracker. When a core developer contacts you, discuss the proposed enhancement with them.

For instructions on how to submit a pull request for your new feature, please review Changing Code and Submitting Your Changes

  • Provide Miscellaneous Information - inevitably, there is a wealth of information wihch the community would benefit from but that nobody has yet provided. We welcome contributions of all types of project-information, such as test scenarios and results in various environments, performance tests and results, How To or API documentation, and any other information you think the community will be able to use. Check the bugs in the GitHub Issue Tracker in the Project Norman sub-project repository you interested in contributing to. You might be able to provide further information, or a hint that helps other contributors understand the bug.

  • Assist other users - you can contribute valuably to BUILD by helping others users who need support. You can check SAP Community Network (SCN) for support requests.

## Using the GitHub Issue Tracker

Please review our our Communications Guidelines document before posting on the GitHub Issue Tracker. You can use the Issue Tracker of the relevant sub-project to do the following:

  • Ask Questions - you can ask our core development team, or any contributors viewing issues in the Issue Tracker, question regarding anything and everything in BUILD.

  • Report Bugs - you can report bugs, or review and have conversations with other contributors about existing issues with the Bug label.

### Asking Questions Using Issue Tracker

  1. Click the New Issue button in the Issue Tracker of the relevant sub-project.

  2. Include the text #Question in the title of issue.

  3. Ensure the summary reflects the essence of your question, to enable community members to identify if it is releveant to them.

  4. Click the Submit Issue button.

    Once an Issue has been created, you can click comment to add further comments or respond.

Proposing Enhancements Using Issue Tracker

New feature or enhacement proposals can be created using the GitHub Issue Tracker for each sub-project.

Include the text #Feature Enhancement in the title of issue.

Click the Submit Issue button.

Once an issue has been created, you can click comment to add further comments or respond.

Changing Code and Submitting Your Changes

Use the following procedure to change code, whether it is a bug fix or a new feature, and submit your changes:

  1. Review the Apache License which outlines both your and the Project Norman Open Source Community's legal rights regarding your contribution.

  2. Download, read, sign, and send us our Individual Contribution License Agreement if you want to submit code as an individual. Alternatively, if you want to submit code on behalf of your employer, a company representative authorized to do so needs to download, fill, and print the Corporate Contributor License Agreement form.

  3. Fork the sub-project repo. For more information, see Fork a Repo.

  4. Install the required dependancies and tools.

  5. Implement your new feature or bug fix on your branch, taking the following into consideration:

Base all your work off of the master branch. Please name your branch to match the new feature of bug fix that you are submitting. Please do not submit more than one feature or bug fix per pull request. Implement your new feature or bug fix on your branch. For consistency, and to enhance the chances that your contribution will be passed for review without corrections required, ensure that your code conforms to our current approach. For more information, see the Project Norman Style Guide. Be sure your author field in Git is filled out correctly, including full name and email address. This enables us to credit you for your contribution. 6. Perform the requisite pre-pull request testing procedures. Please include tests to prove your code works.

A link to a comprehensive guide to testing new code prior to submitting your pull request will be inserted shortly.

  1. Push the changes on your fork, and submit pull request for original repository. Fore more information, see Using Pull Requests.

Note: For guidelines on commit messages, see the Project Norman Style Guide.

  1. When you have submitted a pull request, a reviewer on the project team reviews your contribution to evaluate whether it can be committed to the master copy of the project, whether further discussion and development for further consideration, or whether it is not accepted as a contribution. It is generally expected that some communication is required with contributors after they have submitted a pull request, and quite rare that a contribution is accepted without qualification on the first attempt. To identify reviewers and committers for each sub-project, click here.

###Links to Contribution-Releated Documents

Clone this wiki locally