Skip to content

Latest commit

 

History

History
96 lines (67 loc) · 3.95 KB

CONTRIBUTING_CLA.md

File metadata and controls

96 lines (67 loc) · 3.95 KB

Contributing to graph-framework-for-microservices

We welcome contributions from the community and first want to thank you for taking the time to contribute!

Please familiarize yourself with the Code of Conduct before contributing.

Before you start working with graph-framework-for-microservices, please read and sign our Contributor License Agreement CLA. If you wish to contribute code and you have not signed our contributor license agreement (CLA), our bot will prompt you to do so when you open a Pull Request. For any questions about the CLA process, please refer to our FAQ.

Ways to contribute

We welcome many different types of contributions and not all of them need a Pull request. Contributions may include:

  • New features and proposals
  • Documentation
  • Bug fixes
  • Issue Triage
  • Answering questions and giving feedback
  • Helping to onboard new contributors
  • Other related activities

Getting started

The framework implements an intuitive DSL and versatile Compiler to implement its objectives. Please refer here for detailed info on getting started.

Contribution Flow

To contribute:

  • Make a fork of the repository within your GitHub account
  • Create a topic branch in your fork from where you want to base your work
  • Make commits of logical units
  • Make sure your commit messages are with the proper format, quality and descriptiveness (see below)
  • Push your changes to the topic branch in your fork
  • Create a pull request containing that commit

We follow the GitHub workflow and you can find more details on the GitHub flow documentation.

Commit Messages

Commit messages should be of the format:

<Summary>

< blank line >

Problem statement - can be description of bug, reason for change, need, ask etc.

< blank line >

Description of fix / code change.

Summary

  • A properly formed git commit subject line should always be able to complete the following sentence If applied, this commit will
  • Do not end the subject line with a period
  • Use the imperative mood in the subject line

Problem statement

  • Separate problem statement from subject, with a blank line
  • Describe why a change is being made.
  • Bullet points are okay.
  • Do not assume the reviewer understands what the original problem was.

Description of fix

  • Separate explanation from problem statement, with a blank line
  • Bullet points are okay, too.
  • Leave out details about how a change has been made, unless it is necessary for clarity.

An example / simple commit message, based on above quidelines.

Add a FAQ page to document important / frequent questions

In our documentation, there needs to be a place for info that come
up a questions frequently. The workflow page is sometime too verbose
to answer such questions quickly.

Add a FAQ page to the docs, where such questions can be captured.

Pull Request Checklist

Before submitting your pull request, we advise you to use the following:

  1. Check if your code changes will pass both code linting checks and unit tests.
  2. Ensure your commit messages are descriptive. We follow the conventions listed here.
  3. Check the commits and commits messages and ensure they are free from typos.

Reporting Bugs and Creating Issues

Please create an issue on the repo using standard GitHub detailed here

Ask for Help

To ask for help, please create an issue on the repo using standard GitHub detailed here