Hi, I agree with you Fabian. Clarifying these issues in the "How to Contribute" guide will save lots of time both to reviewers and contributors. It is a really disappointing situation when someone spends time implementing something and their PR ends up being rejected because either the feature was not needed or the implementation details were never agreed on.
That said, I think we should also make sure that we don't raise the bar too high for simple contributions. Regarding (1) and (2), I think we should clarify what kind of additions/changes require this process to be followed. e.g. do we need to discuss additions for which JIRAs already exist? Ideas described in the roadmaps? Adding a new algorithm to Gelly/Flink-ML? Regarding (3), maybe we can all suggest some examples/patterns that we've seen when reviewing PRs and then choose the most common (or all). (4) sounds good to me. Cheers, Vasia. On 23 September 2015 at 15:08, Kostas Tzoumas <ktzou...@apache.org> wrote: > Big +1. > > For (1), a discussion in JIRA would also be an option IMO > > For (2), let us come up with few examples on what constitutes a feature > that needs a design doc, and what should be in the doc (IMO > architecture/general approach, components touched, interfaces changed) > > > > On Wed, Sep 23, 2015 at 2:24 PM, Fabian Hueske <fhue...@gmail.com> wrote: > > > Hi everybody, > > > > I guess we all have noticed that the Flink community is quickly growing > and > > more and more contributions are coming in. Recently, a few contributions > > proposed new features without being discussed on the mailing list. Some > of > > these contributions were not accepted in the end. In other cases, pull > > requests had to be heavily reworked because the approach taken was not > the > > best one. These are situations which should be avoided because both the > > contributor as well as the person who reviewed the contribution invested > a > > lot of time for nothing. > > > > I had a look at our “How to contribute” and “Coding guideline” pages and > > think, we can improve them. I see basically two issues: > > > > 1. The documents do not explain how to propose and discuss new features > > and improvements. > > 2. The documents are quite technical and the structure could be > improved, > > IMO. > > > > I would like to improve these pages and propose the following additions: > > > > 1. Request contributors and committers to start discussions on the > > mailing list for new features. This discussion should help to figure out > > whether such a new feature is a good fit for Flink and give first > pointers > > for a design to implement it. > > 2. Require contributors and committers to write design documents for > all > > new features and major improvements. These documents should be attached > to > > a JIRA issue and follow a template which needs to be defined. > > 3. Extend the “Coding Style Guides” and add patterns that are commonly > > remarked in pull requests. > > 4. Restructure the current pages into three pages: a general guide for > > contributions and two guides for how to contribute to code and website > with > > all technical issues (repository, IDE setup, build system, etc.) > > > > Looking forward for your comments, > > Fabian > > >
