Skip to content
This repository has been archived by the owner on Apr 16, 2024. It is now read-only.

Latest commit

 

History

History
97 lines (67 loc) · 4.76 KB

CONTRIBUTING.md

File metadata and controls

97 lines (67 loc) · 4.76 KB

Contributing

Warning: This is a WIP

idp-scim-sync is Apache 2.0 licensed and accepts contributions via GitHub pull requests. This document outlines some of the conventions on to make it easier to get your contribution accepted.

We gratefully welcome improvements to issues and documentation as well as to code.

Certificate of Origin

By contributing to this project you agree to the Developer Certificate of Origin (DCO). This document was created by the Linux Kernel community and is a simple statement that you, as a contributor, have the legal right to make the contribution.

  • All contributors to idp-scim-sync must sign off each contribution (usually this means each commit).The signature must contain your real name (sorry, no pseudonyms or anonymous contributions). If your user.name and user.email are configured in your Git config, you can sign your commit automatically with git commit -s.
  • Each commit sign off will be reviewed by the idp-scim-sync maintainer (by taking a look at their email address and Github profile) before merging the contribution.

References:

Understanding idp-scim-sync

If you are entirely new to idp-scim-sync, you might want to take a look at:

Understanding the code

To get started with developing idp-scim-sync, you might want to check the following:

Mocks

These are generated using gomock project.

For better integration I use go:generate to run gomock command inside files when mocks are needed

Practices

How to run the test suite

Prerequisites:

make test

Clean up the test output:

make clean

Acceptance policy

These things will make a PR more likely to be accepted:

  • a well-described requirement
  • tests for new code
  • tests for old code!
  • new code and tests follow the conventions in old code and tests
  • a good commit message (see below)
  • all code must abide Go Code Review Comments
  • names should abide What's in a name
  • code must build on both Linux and Darwin, via plain go build or using make build-dist
  • code should have appropriate test coverage and tests should be written to work with go test ./... or make test

Format of the Commit Message

Try to follow Conventional Commits or Semantic Commit Messages