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 >
