As for >add the guide to our repository<, it means check in guide files under docs/, possibly docs/flinkDev. If we exclude details of the guide from the doc site, maybe somewhere else.
Best, tison. Stephan Ewen <se...@apache.org> 于2019年6月13日周四 下午3:54写道： > 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 > > > > > >
