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
>>>> 
>>> 
>> 

Reply via email to