>>>>> Dominic, I appreciate that you cannot commit to two-week time-frame
>>>>> for reviews, and that’s exactly my point — you are busy as is, and we
>>>>> cannot rely on just you doing the reviews.
>>> +1 - no single person can scale, and burnout is a major risk if we try it.
>>
>> The context of what I said isn't clear here, as I wasn't offering to
>> do any more work than I currently do or to burn myself out trying.
>>
>> My point was that the threat of something being merged isn't going to
>> make me review it any faster. It would be unbearable if everybody
>> started nagging or threatening as a matter of course, so I really don't
>> wish for it to begin now.
>
> Thanks for clarifying, and I have to agree with you - that's one of
> the reasons I said it's not perfect solution (and to be fair, it's
> definitely not you that needs to do more reviews!).
>
> My point about scale was not to say you'd do more work - it is that
> even if all reviewers reprioritise now, we just delay the issue, or
> cause it to crop up somewhere else. There's a finite pool of review
> time, and the solution to that is more reviewers.
There is only a finite pool of reviews as well, particularly in this
repo. We don't have to flood the repository with reviewers to solve the
problem forever, simply increase it in a rough proportion to the PR
activity over time.
> Can you clarify further on
> whether you do want things to remain as they are? If so, can you
> address my point about how to encourage that re-prioritising effort
> for other reviewers? If we can come up with something workable for
> that, then I think it would be a good way forward, but asking nicely
> has been the strategy for a long time, and I don't see much change.
Yes, I do want the general framework to remain as it is, as I think it's
workable. I don't really know how to encourage other reviewers, I
suspect our motivations are all quite different! You do list some good
ideas below though.
> In the interest of trying to provide solutions rather than problems,
> I'll risk adding some of my longer term thoughts here - feel free to
> pick up on these if they seem useful to the debate, but only if so - I
> don't want to derail this thread.
>
> * "Open reviews" section of the website (yes, this data is on the
> github labels, but collating it may help)
> * Publishing review stats (maybe a top-ten reviewers leaderboard?) to
> encourage participation
All good ideas! They may indeed help.
> * Adding a minimum reviews-per-timeperiod requriement to being a
> committer (not sure i like this, but other projects use it))
I'm unsure if this would help with increasing the number of reviews that
committers perform, I suspect it would mostly reduce the number of
committers.
It's more likely to ensure that the people who are carrying out reviews
are more aware of what's going on, possibly leading to better quality
reviews, rather than quantity.
> * Encouraging community members to review/test code as a way of
> getting started with contributing (still needs a committer to
> sanity-check and merge, but you can't become a committer if you don't
> review)
Also good, though requires more documentation and effort to ensure
people know how to test different types of patches.
e.g. users struggle to test some kinds of patches on packaged
installations because things like bundler, bundler_ext, asset
precompilation, apipie caches can make it confusing or difficult to
apply patches "raw". Nothing's insurmountable though, and all these
minor issues will have various technical or documentation solutions to
make it easy for people to test things.
···
On 10/11/15 12:27, Greg Sutcliffe wrote:
> On 10 November 2015 at 11:58, Dominic Cleal wrote:
>> On 10/11/15 11:27, Greg Sutcliffe wrote:
>>> On 10 November 2015 at 11:07, Dmitri Dolguikh wrote:
–
Dominic Cleal
dominic@cleal.org
