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