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 >
