Hi Joe, Thanks for starting this thread! It seems the proposal emphasizes documentation and test coverage, which are normal practices in releasing a large software.
It looks all good but the point is that how you'd like to apply it? We have a checklist in the PR template and @flinkbot will toast a checklist which, unfortunately, is almost ignored in most cases. A process may work or help but all in all, it depends on committers who moderate and merge the pull request. The Rust community defines a Final Comment Period (FCP)[1] for attention on documentation and robust behaviors. You may think of it with our FLIP process. For tests and every PR documents, updating the template and bot toast, and letting the consensus becomes one in every committer is more important and easy to exercise. A new process cannot ensure a PR is well tested logically, it creates formalism. Best, tison. [1] https://rustc-dev-guide.rust-lang.org/getting-started.html#breaking-changes Johannes Moser <j...@ververica.com> 于2021年11月16日周二 上午5:36写道： > Dear Flink Community, > > We as the release managers of the 1.15 release are suggesting to introduce > a “Definition of Done". > > Let me elaborate a bit on the reasons: > * During the release process for 1.14 the stability of master was > sometimes in a state that made contributing to Apache Flink a bad > experience. > * Some of the changes that have been contributed seem to be unusable by > users because of defects. > * Documentation is neglected which also leads to users unable to make use > of changes. One of the reasons is, because documentation is often pushed to > a later state. > > With this definition of done awareness and sensibility for these aspect > should be increased. Both, for the ones who are committing and for the ones > that are reviewing. > We focus on code quality, testing and documentation. A shared > understanding is created. > > The Definition of Done as suggested: > > - > A PR is done and can be merged, when: > > 1. It is following the code contribution process > 2. It is implemented according to the code style and quality guide. > 3. If it has user facing changes the documentation has been updated > according to the documentation style guide. > 4. It is covered by tests. > 5. All tests passed. > - > > There are two PRs to illustrate the changes. > https://github.com/apache/flink-web/pull/481 < > https://github.com/apache/flink-web/pull/481> > https://github.com/apache/flink/pull/17801 < > https://github.com/apache/flink/pull/17801> > > > It isn’t the goal to make it harder to get changes into Apache Flink. It > is rather the opposite of making contributing and using Apache Flink a > better experience. > By creating awareness a push towards quality and usability should happen. > > I’m happy to hear your feedback. > > Best, > Joe
