This is a very good idea and will greatly help contributors. The requirements to submit code to this Malhar folder should be very minimal. A few that come to my mind
- Should compile - License of the external lib (if any) should be Apache compliant license // Need to see if this is part of ASF guidelines Everything else including naming, idempotency, performance, ... should be waived. Thks Amol On Thu, May 26, 2016 at 11:25 PM, Pramod Immaneni <pra...@datatorrent.com> wrote: > As you all know the continued success and growth of an open source project > is dependent on new members joining the project and contributing. This will > depend on how accessible the project is for new folks to make meaningful > contributions. For a project like ours where the code base has been in > development for years, it can be quite daunting for new members to just > pick up and make contributions. We need to find ways to make it easier for > people to do so. Malhar, namely the operator library, is an area where > people can contribute without requiring deep knowledge or expertise. > > We have seen operators take time to mature as evidenced by the road taken > by some of our commonly used operators to reach production quality. This is > due to the fact that apart from the core functionality the operator is > trying to implement there are many other aspects to address such as > performance, idempotency, processing semantics and scalability. It would be > difficult even for folks familiar with all these aspects to get everything > right the first time around and produce comprehensive operators let alone > first time contributors. At the same time operators cannot reach this > maturity level unless they get used in different scenarios and get a good > look at by different people. In maturity I am also including API stability. > > I would like to propose creation of a space inside Malhar, a sub-folder, > where contributions can first go in if they are not fully ready and when > they mature can be moved out of the sub-folder into an existing module or a > new module of its own, the package paths can remain the same. The > evaluation bar for contributions into this space would be more permissive > than it is today, it would require the functionality the operator was > developed for be working but will not necessitate that all fault tolerant > and scalability aspects be addressed. It will also allow new operators that > are variations of existing operators till such time as we can determine if > the new functionality can be subsumed by the original operator or it makes > sense for the new operator to exist as a separate entity. It will be up-to > committers and contributors to work together and make the decisions as to > whether the individual contributions go into this space or are ready to > just go into the regular modules. > > What does everyone think. > > Thanks, > Pramod >
