I like the idea of using contrib for this end. On Fri, May 27, 2016 at 7:57 AM, Thomas Weise <[email protected]> wrote:
> That's a good proposal. Sounds like an "incubator" space inside Malhar. > > Originally that was the intention behind the contrib module. But now it > contains many connectors that should be promoted to their own modules. So a > possible route would be to use contrib for early/evolving code and then > promote as it matures. > > In any case the expectations need to be documented: > > http://apex.apache.org/contributing.html > > Currently these guidelines skip everything till submitting PR, we need to > update them to give newcomers a better picture. > > Thomas > > > On Thu, May 26, 2016 at 11:25 PM, Pramod Immaneni <[email protected]> > 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 > > >
