Skip to content

Latest commit

 

History

History
86 lines (59 loc) · 4.88 KB

CONTRIBUTING.md

File metadata and controls

86 lines (59 loc) · 4.88 KB
Raw

Table of Contents

This repo adheres to the SaasBase development guideline: SaasBase Contribution Guide

We are using the fork-pullrequest-merge model to integrate new fixes/improvements in our mainline repository: git@git.corp.adobe.com:adobe-apis/api-gateway-request-tracking.git

###Roles

  • Contributors: Any active Api-Gateway developer or other Adobe contributor
  • Maintainer : One of the Api-Gateway developers doing pro-bono repository maintanance

###Terms

  • Main repository: master branch in git@git.corp.adobe.com:adobe-apis/api-gateway-request-tracking.git repository governed by strict integration policy (i.e: master branch is always stable, ready for release)
  • Contributors workspace :

###Contributing to this repository

  1. A Contributor SHALL file a JIRA issue, assuming one does not already exist, clearly describing the issue including steps to reproduce when it is a bug.

  2. To work on an issue, a Contributor SHALL create a new feature branch within adobe-apis/api-gateway-request-tracking repo:

     git checkout -b WS-999 origin/master

  3. During the development process, a Contributor SHALL ensure the following requirements are met:

    • Code-style is followed:
      • 4 space indentation, no tabs for puppet and scripts
      • Google Code Style for Java
    • Documentation is added/updated (internal/external)
    • Nginx specific integration tests all pass
    • Update Release Notes file and fill in the comments section of CHANGES.txt file external customer configuration instructions

  4. To submit a patch, a Contributor SHALL ensure that commit message is properly formatted:

    • The commit title should contain the Jira ID and description
      • e.g. [WS-999] - Jira description
      • The following lines could have a detailed description if needed.
      • When the commit is (exceptionally) appending to a previous commit use the following template:
        • [JIRA-ID] Jira Issue Title ADDENDUM
    • There a couple of exceptions to the rule above when a JIRA issue is not required.
      However a review is still encouraged mostly because it keeps changes clean and the team informed.
      • [DOC] - Description of the documentation change
      • [COSMETIC] - Description of cosmetic change
      • [RELEASE] - Commit to crease a release artefact

  5. To submit a patch, a Contributor SHALL create a pull request on git.corp.adobe.com back on adobe-apis/api-gateway-request-tracking project.
    The team will be notified via email about the new PR

     git push -u origin WS-999:WS-999

  6. Repo Maintainers and other Contributors are reviewing the pull-request on git.corp.adobe.com giving feedback and proposing changes if necessary.
    A reviewer agrees on the final version of the patch by posting a +1 message on pull-request discussion thread.

  7. Once the patch is reviewed and accepted by at least two maintainers and has no vetoes, the patch is accepted and ready to be pushed into the main repository.

  8. Contributors SHALL squash individual commits in the pull-request.

  9. Contributor SHALL rebase the feature branch on top of latest chages in origin/master and SHALL push a single commit into the main repository

     git fetch origin
 git rebase -p origin/master
 git push origin WS-999:master

  10. Contributor marks the JIRA issue as Resolved and updates the Fix Version field accordingly

###Must-reads