asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Murtadha Hubail <>
Subject Re: [DISCUSS] Improving reviews
Date Wed, 07 Dec 2016 15:31:04 GMT
I’m for any type of improvement of the current code review process. Currently, I have only
few hours a week to contribute to the project and almost every week I start working on a new
change. As the number of touched classes on the change increases, I just decide to abandon
it and start looking for another change that might be smaller. I do this because I know the
bigger change will be stuck in the code review queue and when that happens I feel discouraged
from contributing and my contribution doesn’t add a value to the system.

Even though the proposed idea might not solve all the issues in the current code review process,
I believe it is definitely going to improve it (and encourage more contributions). 

> On Dec 6, 2016, at 9:49 AM, Till Westmann <> wrote:
> Hi,
> today a few of us had a discussion about how we could make the reviewing
> process moving along a little smoother. The goal is to increase the likeliness
> that the reviews and review comments get addressed reasonably quickly. To do
> that, the proposal is to
> a) try to keep ourselves to some time limit up to which a reviewer or author
>   responds to a review or a comment and to
> a) regularly report via e-mail about open reviews and how long they have been
>   open (Ian already has filed an issue to automate this [1]).
> Of course one is not always able to spend the time to do a thorough review [2]
> / respond fully to comments, but in this case we should aim to let the other
> participants know within the time limit that the task is not feasible so that
> they adapt their plan accordingly.
> The first proposal for the time limit would be 72h (which is taken from the
> minimal time that a [VOTE] stays open to allow people in all different
> locations and timezones to vote).
> Another goal would be to abandon reviews, if nobody seems to be working on them
> for a while (and we’d need to find out what "a while" could be).
> Thoughts on this?
> A good idea or too much process?
> Is the time limit reasonable?
> Please let us know what you think (ideally more than a +1 or a -1 ...)
> Cheers,
> Till
> [1]
> [2]

View raw message