Is there an example from prior PRs where it was not accepted/merged due to a disagreement between a contributor and a committer on the amount of refactoring or code quality?
Thank you, Vlad > On Jan 27, 2019, at 06:56, Chinmay Kolhatkar <chinmaykolhatka...@gmail.com> > wrote: > > +1. > > On Sat, 26 Jan 2019, 11:56 pm amol kekre <amolhke...@gmail.com wrote: > >> +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 >>>> >>> >>
