+1 for this proposal. The only caveat I have is -> "acceptable performance and resolving logical flaws identified during the review process"
is subjective. Functionally working should cover any logical issues. Performance should be applicable only to bug fixes and small enhancements to current features. I will word is as "do not degrade current performance significantly". Amol On Fri, Jan 25, 2019 at 9:41 PM Sanjay Pujare <sanjay.puj...@gmail.com> wrote: > +1 > > > On Fri, Jan 25, 2019 at 5:20 PM Pramod Immaneni <pramod.imman...@gmail.com > > > wrote: > > > Our contributor and committer guidelines haven't changed in a while. In > > light of the discussion that happened a few weeks ago, where > > high commit threshold was cited as one of the factors discouraging > > submissions, I suggest we discuss some ideas and see if the guidelines > > should be updated. > > > > I have one. We pick some reasonable time period like a month after a PR > is > > submitted. If the PR review process is still going on *and* there is a > > disagreement between the contributor and reviewer, we will look to see if > > the submission satisfies some acceptable criteria and if it does we > accept > > it. We can discuss what those criteria should be in this thread. > > > > The basics should be met, such as code format, license, copyright, unit > > tests passing, functionality working, acceptable performance and > resolving > > logical flaws identified during the review process. Beyond that, if there > > is a disagreement with code quality or refactor depth between committer > and > > contributor or the contributor agrees but does not want to spend more > time > > on it at that moment, we accept the submission and create a separate JIRA > > to track any future work. We can revisit the policy in future once code > > submissions have picked up and do what's appropriate at that time. > > > > Thanks > > >
