<div dir="ltr"><div><span style="font-size:12.8px">I sent this to Alessandro only instead of the whole list by accident! </span></div><span style="font-size:12.8px"><div><span style="font-size:12.8px"><br></span></div>From the discussion so far, it seems that there is no common and well understood "standard operating procedure" or "policies" for such issues. QGIS, QGIS Core group, clients, paid and unpaid developers by clearly outlining each person's role and responsibility and minimizing friction could benefit everyone. </span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">For this issue, two tools come to mind:</div><div style="font-size:12.8px">----------------------------------------------------</div><div style="font-size:12.8px">1. A project selection matrix based on the "triple bottom line" (TBL) principles as they relate to QGIS's project and executive vision. For a hypothetical example, the main variables could be "Increase in usage of QGIS by different users", "Reduce errors and inconsistencies", "addin/plugin helps solve an environmental problem and therefore can contribute to GHG emissions reductions", "plugin could generate outside revenue through consulting, hiring of staff, etc", "add in / plugin could help QGIS be implemented at the corporate level", "add in / plugin lines up with QGIS corporate and open source goals". </div><div style="font-size:12.8px">With this tool a group of technical experts an QGIS board would form a a committee and meet to discuss potential projects, let's say once a month. In that two hour online meeting, they would score each projects based on all the variables at hand. </div><div style="font-size:12.8px">These scores would be combined into a matrix such as the following <a href="http://bestbusinessprocess.com/wp-content/uploads/2014/03/Matrix.jpg" target="_blank">http://bestbusinessprocess.com/wp-content/uploads/2014/03/Matrix.jpg</a> . </div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">2. When projects are scored through the TBL and plotted in the quadrant chart, QGIS committee can then take them through a project selection flow chart that would determine whether this will be done for free, money, expected timelines,what are the benefit to cost ratio, etc.. For example, if a project is a "quick-win", the core committee might decide to take someone off an existing project and assign them to that; On the other hand, if the project / add in is considered a "fill-in" as in a low priority for the client, QGIS, community, and vision, then the prospective client can pay to get the plug-in developed.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I think there is an opportunity here to develop some "Standard Operating Procedures" in QGIS to make the process capable and predictable, as in if at any point in time, someone submits a new idea, the path to development, for hire, or rejection is clearly understood and replicable.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">These are my two cents. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 10, 2015 at 4:05 AM, Alessandro Pasotti <span dir="ltr"><<a href="mailto:apasotti@gmail.com" target="_blank">apasotti@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">2015-11-10 8:52 GMT+01:00 Hugo Mercier <span dir="ltr"><<a href="mailto:hugo.mercier@oslandia.com" target="_blank">hugo.mercier@oslandia.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, that would be ideal.<br>
<br>
But do we have enough money for that ?<br>
And is it a full time job ?<br>
<br>
Or to put it another way: what is the budget we can assign for this task ?<br>
<span><br></span></blockquote><div><br></div></span><div>The only concern I have with <a href="http://QGIS.ORG" target="_blank">QGIS.ORG</a> hiring a full/part-time dev is that could be hard to find a single developer that can review all parts of the code.<br><br></div><div>I'd prefer if <a href="http://QGIS.ORG" target="_blank">QGIS.ORG</a> does the coordination part with internally financed resources and delegates/outsource the code review to a pool of core-devs.<br><br></div><span class=""><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
On 09/11/2015 23:59, Nathan Woodrow wrote:<br>
> The main problem I see in having a formal pay to review/merge model, no<br>
> matter the scale, is that it is a pay to win model no matter how to<br>
> goes.  If you have the money you can pay someone to push it though<br>
> quicker which doesn't give others the same ability if they don't have<br>
> the cash.<br>
><br></span></blockquote><div><br><br></div></span><div>It depends on the individual PR, if it's the amazing cool new feature that everybody was waiting for, I suspect that some volunteers code reviewer will show up anyway.<br><br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> Personally the only way I can see this model working is if we have a<br>
> full time dev for the project that can review most PRs, or the <a href="http://QGIS.ORG" rel="noreferrer" target="_blank">QGIS.ORG</a><br>
</span>> <<a href="http://QGIS.ORG" rel="noreferrer" target="_blank">http://QGIS.ORG</a>> board can allocate funds to a core dev to review a set<br>
<span>> of PRs. This way the project is in control and not "Hey X, I have a<br>
> stack of cash here. Be a buddy and merge my stuff for me will ya"<br>
><br></span></blockquote><div><br></div></span><div><br>What we need to avoid is that somebody pays for a feature and that it's included no matter how it is. But the quarantine for the core-devs and the QEP+code review for all others should work in that case.<br><br></div><div>The advantages in having the PR queue managed by <a href="http://QGIS.ORG" target="_blank">QGIS.ORG</a> is that it's more neutral if compared with just hiring a core-dev to bypass the whole process.<br><br></div><br><br></div><span class="">-- <br><div>Alessandro Pasotti<br>w3:   <a href="http://www.itopen.it" target="_blank">www.itopen.it</a></div>
</span></div></div>
<br>_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
List info: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Ahmed Dassouki<br></div>
</div>