Thanks for your proposal, Stamatis. IMHO, "IN REVIEW" state is not necessary since it somehow tells people this PR is under review by someone which may discourage others to review it for both committers and contributors.
I do agree that what is really helpful is if people could assign PRs to themselves on GitHub when they agree to review them. Best, Chunwei On Tue, Jul 23, 2019 at 9:45 PM Michael Mior <[email protected]> wrote: > I would strongly oppose limiting who can review code. Only committers > can actually commit code, so we already have a mechanism for limiting > what code makes it in. I haven't seen anyone give a really bad code > review and if that does happen, I would rather address it on a case by > case basis instead of discouraging people from reviewing code. > > On the topic of making it easier to review PRs, what would be helpful > for me is if people could assign PRs to themselves on GitHub when they > agree to review them. It makes it a lot easier to find ones which are > languishing when I have a bit of spare time to review PRs. I think > this is a relatively easy process since it's just one extra click if > you're viewing the PR on GitHub. > > -- > Michael Mior > [email protected] > > Le lun. 15 juil. 2019 à 22:19, Danny Chan <[email protected]> a écrit : > > > > Sounds like a good idea if this state can only be seen by > committers/PMC, because we should keep the quality of code reviewing, we > should make some limit on who can review the code, as far as I know, many > contributors are not that familiar with our code, and usually a good review > comes from committers or even only from Julian ！ > > > > Best, > > Danny Chan > > 在 2019年7月15日 +0800 PM11:47，Stamatis Zampetakis <[email protected]>，写道： > > > Hello, > > > > > > I was thinking that it would be helpful if we had an additional JIRA > state > > > stating that the ticket is under ongoing review. > > > > > > It would help to better monitor progress and provide more insights > towards > > > the release. > > > > > > Having an assigned reviewer (most often a committer) would mean that > this > > > person is going to help resolving the ticket for the next release (or > find > > > somebody else to delegate this task). That doesn't mean that other > people > > > should not participate in the discussion, however if things block > he/she > > > should be the first person to take action. > > > > > > What do you think? > > > > > > If there are not any objections, I will create an INFRA ticket. > > > > > > Best, > > > Stamatis >
