Thanks again, Fabian for starting the discussions. For (1) and (2) I think it is good idea and will help people to understand and follow the author thought process. Following up with Stephan's reply, some new features solutions could be explained thoroughly in the PR descriptions but some requires additional reviews of the proposed design. I like the idea of using tag in JIRA whether new features should or should not being accompanied by design document.
Agree with (3) and (4). As for (3) are you thinking about more of style of code syntax via checkstyle updates, or best practices in term of no mutable state if possible, throw precise Exception if possible for interfaces, etc. ? - Henry On Wed, Sep 23, 2015 at 9:31 AM, Stephan Ewen <se...@apache.org> wrote: > Thanks, Fabian for driving this! > > I agree with your points. > > Concerning Vasia's comment to not raise the bar too high: > That is true, the requirements should be reasonable. We can definitely tag > issues as "simple" which means they do not require a design document. That > should be more for new features and needs not be very detailed. > > We could also make the inverse, meaning we explicitly tag certain issues as > "requires design document". > > Greetings, > Stephan > > > > > On Wed, Sep 23, 2015 at 5:05 PM, Vasiliki Kalavri <vasilikikala...@gmail.com >> wrote: > >> 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 >> > > >> > >>
