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 > > >
