You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apex.apache.org by tweise <gi...@git.apache.org> on 2016/08/09 17:59:01 UTC

[GitHub] apex-site pull request #44: Added malhar contribution guidelines

Github user tweise commented on a diff in the pull request:

    https://github.com/apache/apex-site/pull/44#discussion_r74111044
  
    --- Diff: src/md/malhar-contributing.md ---
    @@ -0,0 +1,41 @@
    +# Malhar Contribution Guidelines
    +
    +Malhar library predominantly contains different kinds of operators like connectors to messaging systems, databases, key-value and document stores, block i/o operators like various file system operators, analytic and algorithmic operators and other miscellaneous operators. It also provides other components to build applications such as partitioners, stats listeners, stream codecs and state management. This document outlines the general steps for making contributions to Malhar. Even though the processes described in the rest of the document refer to Operators in particular, they also generally apply to other application components mentioned above.
    +
    +## Operators
    +
    +* Follow the unix philosophy, design your operator to do one thing and do it well. If the operator is doing multiple things, you may not be taking advantage of platform parallelism aspects like pipelining to the fullest extent (akin to unix pipes). 
    +
    +* Search Malhar project to see if there is an operator with similar functionality before embarking on writing a new one
    +	* If an operator that is supposed to solve the same problem is already present but isn\u2019t complete or does not have the required functionality, consider making improvements to it. There should be a strong reason to not do this and create a new one. 
    +	* If there is an overlap in functionality with an existing operator or an operator that is designed to be extended, do not rewrite that functionality. Create the new operator in such a way that it reuses code already present and implements the new functionality on top of it. This might require refactoring of existing operator(s).
    +* If the functionality requires connecting two or more operators together, do that in the application. If this pattern would be useful to others and can be reused in other applications consider making it a module.
    +  
    +## Updating an existing Operator
    +
    +If after performing the above analysis, there is a need to update an existing operator, follow these steps
    +
    +* Make the case on dev email list as to why an update is needed and propose any design that you are thinking of.
    +* Specify which module you are going to submit the operator or contrib if the operator is not going to have any platform functionality. See implementing an operator section below.
    --- End diff --
    
    Module is used with different meaning in multiple places.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---