Re: [boost] [review queue] What to do about the library review queue?

Subject: Re: [boost] [review queue] What to do about the library review queue?
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2017-03-14 23:17:13

Le 14/03/2017 à 23:41, Steven Watanabe via Boost a écrit :
> AMDG
>
> On 03/14/2017 04:26 PM, Glen Fernandes via Boost wrote:
>> On Tue, Mar 14, 2017 at 6:12 PM, Raffi Enficiaud wrote:
>>> I suggest another way of rewarding people:
>>>
>>> - If the review manager is a library maintainer: by the end of the review,
>>> he/she gets the help of the boost community (including the ppl whose code is
>>> being reviewed) to get his/her backlog cleared. This includes development,
>>> patches, backlog cleanup, as well as management/coordination of those devs.
>>>
>>> - if the review manager is the author of a library under review or freshly
>>> reviewed for acceptance to boost, but still not part of any release: he/she
>>> will get the help of the boost community
>>> to make that happen as soon as possible (including open pending issues from
>>> previous reviews, documentation, integration, migration to boost.build, etc
>>> etc)
>>>
>>> Of course, we can iterate further
>>> - for each good and sound review, you get one ticket of your backlog closed
>>> by next release
>>>
>>
>> These actually sound like excellent ideas to me.
>>
>
>   Yes, it sounds great to me too, but...
> who is volunteering to do this work?
> "The boost community will do it" is much
> to nebulous for a practical proposal.
>

Of course! I was suggesting another reward model, which apparently 
triggers attention and might benefit to all by offloading work.

I do not have very specific solutions for that, but I believe we can 
converge quickly to something that can be close to consensual.

========================
Just throwing ideas there:

A- case "one review -> one ticket closed":

   1- best case: some one volunteers, contacts the reviewer and ask how 
he/she can help, and the reviewer discusses with him/her what can be 
done next (I've done and also seen that)

   2- worst case: no volunteer: falls back to the library author ... or 
the "boost community maintenance team". Community maintenance team may 
for instance hire (with the boost real money) freelancers to do the job,
but will monitor the quality together with the reviewer.

B- case "review manager -> backlog cleared"

   1- best case: several ppl volunteer, ask the review manager what are 
the priorities, and do the work. Integrate that backlog story into the 
agenda of the release managers for the coming release. Rationale: 
without putting that on release manager desk, the work may shift too 
much. If this becomes a general concern for those who have stake on the 
next release, then it will raise awareness.

   2- intermediate case: ask the last 3 library authors whose library 
has already been integrated to boost for at least 2 releases (rationale: 
people still around and having their library in a more steady state than 
right after the first integration to boost). Can be a mix of B.1 and 
B.2, to the demand of the release managers maybe?

   3- worst case: falls back to the library author :-) or the Community 
maintenance team again (same potential solutions as A.1 above)

... and so on

========================

all in all, I think we can just make democracy speak about what are the 
preferences and vote for a sound scheme.

It is always pleasing when ppl volunteer, but I also understand how 
limited we are all in our time and energy. So using some money might 
also be a solution (although can also be controversial or problematic: 
we would not want to hire ppl participating in boost already for instance).

========================

Some design benefits of this model:

- no money involved in the review process: review cleared from any bias 
or motivation other than making boost better
- money might be used only for improving the state of boost (closing 
tickets via freelancers for instance)
- ppl start looking at how to improve other libraries, and get to 
understand the code, reach and collaborate new ppl ... basically 
improves the communication over the code, and leverage potential for 
better collaboration (disclaimer: I am not saying that the collaboration 
is bad), removes the frontier of the submodules, etc...

Best,
Raffi