This should definitely be split up into topics, agreed. And it should be linked form the "how to contribute" page or the PR template to make contributors aware.
On Thu, Jun 13, 2019 at 9:51 AM Zili Chen <wander4...@gmail.com> wrote: > Thanks for creating this guide Stephan. It is also > a good start point to internals doc. > > One suggestion is we could finally separate the guide > into separated files each of which focus on a specific > topic. Besides, add the guide to our repository should > make contributors more aware of it. > > Best, > tison. > > > Jeff Zhang <zjf...@gmail.com> 于2019年6月13日周四 下午3:35写道： > > > Thanks for the proposal, Stephan. Big +1 on this. > > > > This is definitely helpful and indispensable for flink's code quality and > > healthy community growth. > > It would also benefit downstream project to integrate flink easier. > > > > > > Till Rohrmann <trohrm...@apache.org> 于2019年6月13日周四 下午3:29写道： > > > > > Thanks for creating this code style and quality guide Stephan. I think > > > Flink can benefit from such a guide. Thus +1 for introducing and > adhering > > > to it. > > > > > > Cheers, > > > Till > > > > > > On Thu, Jun 13, 2019 at 5:26 AM Bowen Li <bowenl...@gmail.com> wrote: > > > > > > > Hi Stephan, > > > > > > > > Definitely a good guide in principle IMO! I personally already find > it > > > > useful in practice to learn from it myself, and also promote and > > > cultivate > > > > a better coding habit around by referencing it. So big +1 to adopt > it. > > > > > > > > Also want to highlight that we need to make real use of it, and keep > > > > ensuring people are aware of its existence. Adding it to Flink > website > > > > would be nice. We can also adding noticeable link for it to the > > template > > > of > > > > github PR (where this guide really matters) to get attention and > > > exposure. > > > > > > > > BTW, what's the plan on how people can raise new coding-style/quality > > > > related questions, how to expand and adjust the content over time, > how > > to > > > > inform the community of such updates and changes? Maybe we can use > some > > > > tags like "[CODING STYLE]" in dev mailing list for these type of > > > > communications? This can be a separate discussion though if we wish. > > > > > > > > All in all, big +1 for adopting it. > > > > > > > > Bowen > > > > > > > > > > > > > > > > > > > > On Wed, Jun 12, 2019 at 12:32 PM Stephan Ewen <se...@apache.org> > > wrote: > > > > > > > > > Hi all! > > > > > > > > > > I want to propose that we try and adopt a code style and quality > > guide. > > > > Its > > > > > a big endeavor, but I think it's worth trying :-) > > > > > > > > > > The Apache Flink community and contributor base is growing quite a > > bit, > > > > new > > > > > committers and contributors are coming on board frequently. > Everyone > > > > comes > > > > > from a different background and brings a different level of > > experience. > > > > > Different contributors apply different styles, and contributions > are > > > > > naturally of varying code quality. > > > > > > > > > > We are struggling with finding a good balance between: > > > > > > > > > > (1) On the one hand maintaining a certain code standard for a big > > and > > > > > complex system like Flink, to reduce bugs and make future > > contributions > > > > > feasible (and not impossible due to code complexity). > > > > > > > > > > (2) On the other hand, make contributions possible for > > contributors. > > > > This > > > > > means not guarding everything to the point that no contributions > can > > > get > > > > in > > > > > any more. > > > > > > > > > > My suggestion to help with this is to define a standard and > document > > it > > > > > explicitly. It will help to get everyone on the same page what the > > > > > expectation is, and it helps contributors know what to pay > attention > > > to. > > > > > Such a guide should also help make review more efficient, because > > > > > contributors can know up front what reviewers will look at. > > > > > > > > > > Over the past weeks, I took a look at the current Flink code base > and > > > > > talked to some committers and contributors and tried to come up > with > > a > > > > > proposal that reflects the approaches and standards that many > > > committers > > > > > have adopted lately. > > > > > > > > > > > > > > > > > > > > > > > > > https://docs.google.com/document/d/1owKfK1DwXA-w6qnx3R7t2D_o0BsFkkukGlRhvl3XXjQ > > > > > > > > > > > > > > > This guide is not fix and final, we should discuss it and expand > and > > > > adjust > > > > > it over time. The guide tries to strike a balance between too much > > > > contents > > > > > (don't force someone to read a book before contributing) and being > > > > > comprehensive enough. The guide looks long, but much of it are > > > component > > > > or > > > > > aspect specific parts, like how to deal with new dependencies, > > > > > configuration changes, etc. > > > > > > > > > > I an curious to hear whether you think such a guide is in > principle a > > > > good > > > > > idea. > > > > > If yes, is the one here a good starting point? > > > > > > > > > > Best, > > > > > Stephan > > > > > > > > > > > > > > > > > > -- > > Best Regards > > > > Jeff Zhang > > >
