Versions Compared

Old Version 23

changes.mady.by.user Justin Leet

Saved on

compared with

New Version 24

changes.mady.by.user Matthew Foley

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

As an open source project, Metron welcomes contributions of all forms. The sections below will help you get started.

1. How To Contribute

We are always very happy to have contributions, whether for trivial cleanups, little additions or big new features.

If you don't know Java or Scala you can still contribute to the project. We strongly value documentation and gladly accept improvements to the documentation.  

1.1  Contributing A Code Change

To submit a change for inclusion, please do the following:

  • If there is not already a JIRA associated with your pull request, create it, assign it to yourself, and start progress
  • If there is a JIRA already created for your change then assign it to yourself and start progress
  • If you don't have access to JIRA or can't assign an issue to yourself, please message dev@metron.incubator.apache.org and someone will either give you permission or assign a JIRA to you
  • If you are introducing a completely new feature or API it is a good idea to start a discussion and get consensus on the basic design first.  Larger changes should be discussed on the dev boards before submission.
  • New features and significant bug fixes should be documented in the JIRA and appropriate architecture diagrams should be attached.  Major features may require a vote.
  • Note that if the change is related to user-facing protocols / interface / configs, etc, you need to make the corresponding change on the documentation as well.

  • Also, please indicate impacts to the following (if exist):

    • System Configuration Changes
      • Metron Configuration
      • Metron Component Configuration (sensors, etc)
      • Tech Stack Configuration (Storm, Hbase, etc)
    • Environmental Changes
      • Helper Shell Scripts
      • RPM Packaging
      • Ansible, Ambari, AWS, Docker
    • Documentation Impacts
      • Changes to Wiki Documentation
      • Revisions in Tutorials
      • Developer Guide
      • Expansions in readme's 
    • Changes to System Interfaces
      • Stellar Shell
      • REST APIs
      • Etc...
  • Craft a pull request following the guidelines in Section 2 of this document.  Instructions on how to submit the pull request can be found here. 
  • Pull requests should be small to facilitate easier review. Studies have shown that review quality falls off as patch size grows. Sometimes this will result in many small PRs to land a single large feature.
  • People will review and comment on your pull request.  It is our job to follow up on pull requests in a timely fashion.
  • Once the pull request is merged the person doing the merge (committer) should manually close the corresponding JIRA.

1.2 Reviewing and merging patches

Everyone is encouraged to review open pull requests. We only ask that you try and think carefully, ask questions and are excellent to one another. Code review is our opportunity to share knowledge, design ideas and make friends.  The instructions on how to checkout a patch for review can be found here. 

When reviewing a patch try to keep each of these concepts in mind:

...